各大操作系统误读英特尔文档致内核可被劫持或崩溃

Chipzilla手册更新，请及时打上补丁。

Linux、Windows、macOS、FreeBSD和Xen的某些实现都存在设计缺陷，攻击者可利用该缺陷导致英特尔和AMD计算机系统崩溃。

更糟的情况是，黑客还有可能获取到敏感内存信息或控制底层操作系统功能，也就是能窥探内核内存或劫持机器运行的关键代码。

恶意登录用户或计算机上运行的恶意软件都可以利用该漏洞。不过，这一几乎波及全行业范围的编程缺陷目前已有可用补丁加以缓解。

5月8号CERT发布的公告称，该编号为CVE-2018-8897的安全漏洞，是因为微软、苹果和其他公司错误理解了英特尔和AMD芯片处理某一特定异常的方式。

CERT写道：“该错误似乎是因开发人员对现有文档的解释而产生的。”换句话说，程序员理解错了英特尔和AMD的手册，虽然这些手册可能写得不是特别清楚。

触发中断

问题的核心是 POP SS 指令。该指令从当前程序的堆栈取得用于堆段选择的值，并将该值放入CPU的堆栈选择寄存器。但现代操作系统大多忽略了内存分段问题。CPU会特别处理 POP SS 指令，以便执行中遇到中断时堆栈能保持一致状态。

应用程序可为堆栈选择器即将被 POP SS 指令从堆栈中取出的内存位置设置调试断点。设置了该调试断点后，当应用程序调用 POP SS 指令时，只要处理器访问RAM特定位置读取该堆栈选择器，就会抛出一个特殊异常。

问题就出在这儿。要利用这一情况，紧跟在 POP SS 指令后的那条指令必须是触发中断的INT指令。这些由软件产生的中断有时候是用户程序用以激活内核，让内核为当前进程干活的，比如打开个文件之类。

在英特尔和AMD机器上，紧跟在 POP SS 后面的软中断指令会让处理器进入内核的中断处理过程。然后调试异常就出现了，因为 POP SS 导致该异常被延迟。

操作系统设计者并没有预期到这一点。他们阅读英特尔的x86-64手册，认为内核中断处理过程是在不可中断的状态下开始的。但如今，中断处理过程在初期就遭遇到了非预期的调试异常。

漏洞发现者的技术报告中解释称，这导致了内核的混乱，特定情况下，内核的动作完全依赖于非特权用户所控制的数据。

如果 POP SS 指令执行时调试寄存器设置了堆栈位置访问的断点，且紧跟的指令就是 INT N，那么在进入中断门之后，挂起的 #DB 就会被触发，因为那是最有可能的分支指令。不是不可屏蔽的中断，也不是机器检查异常，操作系统开发人员直接为中断门语义假定了一个不可中断的状态。这会导致操作系统监管软件在设计时出现漏洞，使用中可能会错误地采用了非特权软件选择的状态信息。

这是操作系统提供商因为 POP SS 指令及其与中断门语义互动的文档不清晰不完整而犯下的严重安全疏漏。

其结果就是，在英特尔主机上，用户应用程序可使用 POP SS 和 INT 指令来利用上述的错误理解，控制中断处理过程中的特殊指针GSBASE；而AMD主机上，应用程序可控制GSBASE和堆栈指针。黑客可利用该漏洞触及未分配内存，抽取部分受保护内核内存，最终使内核崩溃；或者调整其内部结构，扰乱系统运行。

虽然任何漏洞利用尝试都更容易搞崩内核而不是引起什么严重伤害，但是与熔断之类的漏洞一样，这是整个行业的耻辱，应该尽快被补上。

操纵

FreeBSD对该问题的解释则更进一步：“在x86架构的系统上，堆栈是由堆栈段和堆栈指针共同表示的，其正常运行需要二者协调一致。操作堆栈段的指令有特殊的处理过程来保持与堆栈指针的改变相一致。”

MOV SS 和 POP SS 指令会抑制调试异常直到下一条指令的边界。如果该指令是一条系统调用或者将控制传递到操作系统的类似指令，调试异常就会在内核环境中处理，而不是在用户环境中处理。

其结果就是通过了身份验证的本地攻击者可以读取到内核内存中的敏感数据，控制底层操作系统功能，或者直接搞崩系统。

微软的内核建议表明，在Windows主机上利用该漏洞，需要攻击者先登录到系统，再运行精心制作的应用程序以夺取受影响系统的控制权。

这并非危言耸听，除非你的主机上从来都不运行任何不可信的代码。

Red Hat 已经准备好放出补丁，Ubuntu和macOS同样做好了补丁准备。

Linux内核早在 2018年3月23号就打上了补丁，版本4.15.14、4.14.31、4.9.91、4.4.125以及更老的4.1、3.16和3.2都已修复。

微软也解决了该问题，补丁覆盖 Windows 7 到 Windows 10，Windows Server 2008 到 Windows Server 1803。Xen为版本4.6到4.10打了补丁。VMware的虚拟机管理程序没有风险，但 vCenter Server 的一个工作区和vSphere集成的容器需要打补丁，但都只是“可能”受影响。

所有资料来源都痛苦地指出，虽然该问题源自x86-64指令集，但需承担责任的却是内核程序员而（不是Chipzilla）。似乎是很多程序员都理解错了调试异常的处理方法，在很长一段时间里重复着相同的错误。

既然英特尔已经更新手册澄清了堆栈选择器指令的处理方式，或许大量操作系统开发人员都得去重新学习x86-64架构。用户也得紧急修复自己的系统——这种事如今用户应该已经非常习惯了。

英特尔发言人称：

我们重视客户和合作伙伴的安全。 为确保与开发者社区的明晰沟通，我们更新了《软件开发者手册》(SDM)，澄清了 POP/MOV-SS 指令的安全用法。我们建议系统软件厂商评估其软件以证实自身产品能处理上述问题。