所有操作系统内核都可能被劫持或崩溃！程序员误读了Intel的文档

在英特尔这家芯片巨头更新手册的同时，赶紧打上那些补丁。

Linux、Windows、macOS、FreeBSD和实现Xen的一些操作系统存在一个设计缺陷；这个缺陷轻则会让攻击者得以使搭载英特尔和AMD芯片的计算机崩溃。

在最糟糕的情况下，攻击者有可能“访问敏感的内存信息或操控低级别的操作系统功能”；换句话说，因而可以窥视内核内存里面的信息，或者劫持运行系统的关键代码。现在已有了可以纠正几乎影响全行业的编程失误的补丁。

正如计算机紧急响应小组（CERT）在周二详细描述的那样（https://www.kb.cert.org/vuls/id/631579），这个名为CVE-2018-8897的安全漏洞似乎是由微软、苹果及其他公司的开发人员引起的，他们误解了英特尔和AMD处理器处理一种特定的特殊异常的方式。

的确，CERT特别指出：“这个错误似乎归咎于开发人员对现有文档解读有误。”换句话说，程序员们误解了英特尔和AMD的手册，这些手册可能不是非常明确。

中断被触发

言归正传。这个问题的核心是POP SS指令，该指令从运行中程序的堆栈中获取一个用于选择堆栈段的值，并将该数值放入到CPU的堆栈选择器寄存器。这完全与现代操作系统基本上忽视的内存分段有关，你可能也忽视了。POP SS指令由CPU专门处理，那样如果该指令在执行时出现中断触发的情况，堆栈不至于处于不一致的状态。

应用程序可以为POP SS将从堆栈获取堆栈选择器的内存位置设置一个调试断点（debug breakpoint）。也就是说，应用程序使用POP SS时，一旦处理器触及内存的某个特定部分以获取堆栈选择器，它就会生成特殊异常。

现在，问题的关键来了。紧跟POP SS指令之后的指令必须是INT指令，该指令触发中断。软件生成的这些中断有时被用户程序用来激活内核，以便内核可以为运行中的进程执行任务，比如打开文件。

在英特尔和AMD机器上，紧跟POP SS之后、软件生成的中断指令促使处理器进入内核的中断处理程序。然后，调试异常被触发，因为POP SS导致了异常被延迟。

操作系统的设计人员没有料到这一点。他们阅读英特尔的x86-64手册后，断定处理程序一开始处于不可中断的状态。而现在在中断处理程序内部的早期阶段就有意料之外的调试异常需要处理。

如果指令POP SS执行，调试寄存器被设置成一访问该堆栈位置就断开，下一个指令又是INT N，那么进入中断门后就会触发等待的#DB，就像它对大多数成功的分支指令所做的那样。操作系统开发人员以为不可中断的状态是从中断门语义授予的，而不是非可屏蔽中断或可能的机器检查异常。这可能导致开发当初想到这些影响的操作系统监控（supervisor）软件错误地使用非特权软件所选择的状态信息。

这是一个严重的安全漏洞，也是操作系统开发商的一大疏忽，起因是介绍POP SS指令及其与中断门语义的相互关系方面的注意事项的说明文档语焉不详，可能甚至不全面。

结果是，在英特尔系统上，用户的应用程序可以控制中断处理程序中的特殊指针寄存器GSBASE；在AMD系统上，用户应用程序可以控制GSBASE和堆栈指针寄存器。这可以用来使内核崩溃（只需让内核触及未映射的内存）、提取受保护的内核内存的一部分，或者篡改内部结构以破坏系统或操纵其操作。

我们认为，任何企图钻空子的尝试更有可能导致内核崩溃，甚至搞任何严重的破坏。不过就bug而言，正如Meltdown那样，这让行业有点难堪；它需要打上补丁，为了安全起见。

操纵手法

针对这个问题的FreeBSD安全公告作了进一步的解释。该操作系统的开发人员写道：“在x86架构系统上，堆栈由堆栈段和堆栈指针这个组合来表示，两者必须保持同步才能指令确保正常运行。与操纵堆栈段有关的指令有特殊的处理机制，以便与堆栈指针方面的更改保持一致。”

“MOV SS和POP SS指令禁止调试异常，直到紧挨下一条指令的指令边界。如果该指令是一个系统调用或将控制权转交给操作系统的类似指令，调试异常就会在内核环境中加以处理，而不是在用户环境中处理。”

结果怎样？“通过身份验证的本地攻击者也许能够读取内核内存中的敏感数据、控制低级别的操作系统功能，甚至可能导致系统崩溃。”

据微软的内核安全公告（https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8897）显示，想在Windows上钻这个漏洞的空子，意味着“攻击者先得登录到系统。然后攻击者运行一个专门编写的应用程序以控制受影响的系统。”

这并不是一种可能性很小的场景，除非你运行的是完全可信任的代码。

Red Hat已准备发布补丁，Ubuntu和苹果MacOS也是如此。

早在2018年3月23日，Linux内核也已得到了修复。版本4.15.14、4.14.31、4.9.91、4.4.125以及更早的4.1、3.16和3.2分支版本已经有了补丁。

微软已拿出了相应的补丁，适用于Windows版本7到10、Windows Server版本2008到1803。Xen为版本4.6到4.10拿出了补丁。VMware的虚拟机管理程序并未面临风险，但vCenter Server有一个变通方法，vSphere Integrated容器在等修正版出来，但两者都只是被评为“可能受影响”。

请参阅上面的CERT链接，了解所有受影响的厂商及其应对情况，必要的话打上相应的更新版。

所有消息人士特别指出，虽然这个问题源自x86-64指令，但要怪内核程序员，而不是怪英特尔。许多程序员似乎只是误解了如何处理调试异常，并且在很长的时间内犯了类似的错误。

英特尔发布了第67版的软件开发者手册，中断方面已作了相应的修改。

众多操作系统开发人员会被公司派去学习强制性的再教育课程，进一步深入了解x86-64架构。现在英特尔已更新了手册，以阐明堆栈选择器指令的处理机制；读者应赶紧打上补丁。

文章来源 云头条