G.O.S.S.I.P 阅读推荐 2022-07-08 Jenny

在电影《阿甘正传》中，那个“Stupid is as stupid does“的Forrest Gump心中念念不忘的女友Jenny给我们留下了深刻的印象（虽然后来她成了美国总统的媳妇）。今天我们为大家介绍另一个Jenny，也就是2022年USENIX Security会议上论文 Jenny: Securing Syscalls for PKU-based Memory Isolation Systems 中提出的安全防护系统，为用户空间的syscall调用提供了安全守护

在这篇由奥地利格拉茨理工大学（TU Graz）的研究人员完成的论文中，作者利用了Intel MPK硬件防护机制（它的另一个为人熟知的名字，也就是论文中的Protection Keys for Userspace，PKU）来对用户空间的syscall调用进行安全防护。我们在过去的一段时间介绍了很多使用MPK/PKU进行安全防护的研究论文（当然我们研究团队也发表了一篇利用MPK/PKU进行防护的SP 2022论文^_^），而这篇论文的独到之处是什么呢，让我们继续阅读。

作者对以往的基于MPK/PKU的syscall监控和过滤机制（即syscall filtering）进行了调研，发现这些已有工作均可被一些复杂的攻击绕过，说明它们的监控和过滤存在一定的设计问题。所以作者在开发Jenny的过程中特别针对性地开展了防御，对syscall interposition（可参考：http://wiki.v2.cs.unibo.it/wiki/index.php/System_Call_Interposition:_how_to_implement_virtualization）技术进行了改进，实现了又快又安全的版本。具体是怎么个又快又安全，我们可以接着看下去。

作者首先提出了一系列新型的攻击，针对MPK/PKU防护下的syscall调用进行劫持（现在撰写安全防护类的论文，你不提出一系列新型攻击都不好意思）。由于Linux中syscall数目众多，现有的防护方案往往忽略了一些比较冷僻的syscall，而攻击者则正是利用了这些syscall开展攻击。举个例子，作者利用了madvise syscall来实施恶意操作——这个syscall本来是用来告诉内核哪些特定的内存区域可以执行相关优化，但是攻击者可以利用这个syscall去操控内核清理特定的内存页面，而这种行为是不受MPK/PKU控制的（MPK/PKU是在用户空间发挥限制的手段）。

作者把这些可被操控、用来攻击MPK/PKU的syscall分为了内存相关、进程相关和文件相关，并在论文的3.2章中进行了详细介绍。接下来，作者指出，在设计安全的基于MPK/PKU的syscall防护方案时，既要考虑到syscall monitor相关的代码和数据不被篡改和非法访问（放在特定的domain中隔离），同时又要保护好MPK/PKU的权限切换指令（即WRPKRU指令）不被非法调用。作者在这里引用了他们自己在2020年USENIX Security上发表的论文Donky: Domain Keys - Efficient In-Process Isolation for RISC-V and x86中的相关思想，设计了一个base-donky的方案。同时注意到Donky方案需要改动硬件，所以作者还设计了另一个在原始的MPK/PKU也能运行的base-mpk方案。这两套方案对内存、文件和进程数据的恶意改动都进行了深入的防护，具体的细节可参考论文的3.3章。作者在下表中总结了Jenny与已有的一些基于bpf和ptrace的syscall filtering方案相比的优势所在：

但凡基于MPK/PKU设计的防护方案都很重视性能和效率，Jenny也不例外，在设计中，作者采用了一个名为“pku-user-delegate”的方式，去处理对syscall的调用监控和代理。传统的设计往往需要基于类似于debugging的机制，即触发中断，由更高一级的代码（例如内核或Hypervisor）来处理异常并监控syscall调用。而Jenny则把这个工作的主要开销放在userspace去做，这样就能提升不少的性能。

在充分考虑了诸多问题之后，作者最后概括了Jenny的工作流程，这里让我们一起回忆一下在6月我们的另一篇论文Unlimited Lives: Secure In-Process Rollback with Isolated Domains（G.O.S.S.I.P 阅读推荐 2022-06-21）中提到的嵌套调用的问题和解决办法，看起来Jenny也受到了那篇论文的影响。

除了对PKRU权限切换进行了严格的防护，确保不会被code reuse attack滥用之外，Jenny还特别对信号（signal）进行了一系列专门的处理（详见论文5.6章），对Signal API、Signal Stack和Signal Handler都做了相关的加固，保证在基于MPK/PKU的sandbox里面也能正确处理各种异常信号。

撇开安全分析不说，针对Jenny的性能测试表明，在部署之后，代码中的syscall调用也就只增加了不到3倍的开销，而利用Seccomp这样的机制，开销往往在20倍以上！

由于syscall调用并不是应用程序的主要开销，所以可想而知在针对现实世界程序测试时，Jenny的表现会很好。作者对dd、git、ls、openssl、zip、ffmpeg等进行了测试，结果表明，那些计算密集型的程序（例如openssl、zip、ffmpeg）几乎不受影响，而比较受影响的是那些调用了大量文件操作类syscall的程序（因为Jenny也特别关注了对文件操作类syscall的滥用防护）

论文PDF：

https://www.usenix.org/system/files/sec22summer_schrammel.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-07-08 Jenny