LWN：OpenBSD针对系统调用的来源进行检验！

关注了就能看到更多这么棒的文章哦～

OpenBSD system-call-origin verification

By Jake Edge
December 11, 2019

原文来自：https://lwn.net/Articles/806776/

OpenBSD内核最近和入了一个新的机制，用来组织return-oriented programming (ROP)这类型的攻击。它可以阻止那些不经过C库（libc）的系统调用wrapper发起的系统调用。这样一来，今后的攻击者就不再能直接调用系统调用了，被迫得转为调用系统调用wrapper，而这些wrapper的地址通常都是在随机不固定的位置。

Theo de Raadt在11月下旬发给OpenBSD tech mailing list的邮件里面介绍了这个功能。基本来说就是限制系统调用只能来自那些获得许可的进程地址空间位置。OpenBSD此前通过W^X方案已经禁止了系统调用从可写page的位置直接发起调用。因为OpenBSD掌控了大多数用户空间应用程序，因此比起Linux更加容易做这种限制，因为Linux没有限制运行在本内核之上的系统和应用程序。尽管如此，最后实现出来的限制方案比起De Raadt期望看到的方案还是不够严格。

最终目标是期望除了libc映射到的区域之外，都不允许调用系统调用。不过目前在OpenBSD平台上的Go语言实现会直接调用系统调用，这样一来，就意味着必须要把程序的text段也要加入可以调用系统调用的信任内存区间了。静态编译的程序也需要允许自己的text段来调用系统调用，因为libc的实现代码被静态链接到了text段。在De Raadt的邮件里面，他介绍了一下目前允许调用系统调用的内存区域：“对静态链接的程序，允许主程序的text段，以及signal trampoline page。针对动态链接的程序来说，会允许ld.so的text段，signal trampoline，libc.so的text段……以及主程序的text段。”

De Raadt很希望Go能切换到libc wrapper去，现在Solaris和macOS上已经做到了。等今后实现了，就可以把主程序的text段从信任区域中移除了：“如果go能在OpenBSD上也适配好，去利用libc函数库来发起系统调用，那就没有问题了。可能还会有一些其他环境也会直接调用系统调用，咱们只能慢慢找了，挨个来fix。”

kernel可以在启动一个进程的时候来对上面提到的大多数区域标记成可信，不过此时它并不知道动态链接程序中libc.so的加载地址。因此就由ld.so dynamic linker(动态链接器)来负责标记这块区域了。因此可以执行一个新增的系统调用msyscall()来标记libc.so所占据的区域为可信区域。每个进程只能调用一次msyscall()，因此在ld.so掉用过一次之后，再也没有机会修改或者新增这个可信区域列表了。任何进程，如果在一个未被允许的区域发起了系统调用，那么就会被直接kill掉。

OpenBSD还有另一个安全措施也会同时起到作用。在启动时，libc在re-link的时候会采用随机的顺序，因此libc内部那些系统调用wrapper的地址在每个运行起来后的系统上都不相同。这样更加让攻击者很难找到这些wrapper的未知，难以采用通用的方法来对远程系统进行攻击了。

OpenBSD的环境变化很快（就像我们在2017年看到的kernel address-space randomized link (KARL)功能），这个patch提出2天之后，就被合入到了OpenBSD tree。对这个操作系统来说，这个改动会导致ABI变化，不过对于OpenBSD来说这不是什么大问题。De Raadt说：“在OpenBSD咱们大家是决定ABI是否稳定的决策者”。他建议大家都不要盲目依赖OpenBSD的现有ABI：“请针对API编程，而不是针对ABI变成。每次当我们发现有好处的时候，都会改动ABI，而API则稳定得多。我修改了这里的ABI，大家祈祷我今后不会对此再做修改吧。”

这是一个增量的安全改善，这个加固措施到位之后，攻击者就很难稳定地利用系统的某个弱点、漏洞了。讨论中基本上没有反对意见，这个改动看起来没有什么争议。不过当今后Go修改完成之后，主程序text段也不再允许调用系统调用的话，也许会有一些受到影响的应用程序开发者跳出来反对了。可惜，对Linux来说，这种类型的ABI改动永远没法被接受。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～