在英特尔芯片巨头更新手册的同时,它很快就能打到这些补丁。
Linux,Windows,macOS,FreeBSD以及一些实现Xen的操作系统都存在设计缺陷;这个漏洞将允许攻击者使用Intel和AMD芯片使计算机崩溃。
在最坏的情况下,攻击者可以“访问敏感的内存信息或操纵低级操作系统功能”;换句话说,您可以查看内核内存中的信息或劫持运行系统的密钥代码。现在有补丁可以纠正影响整个行业的编程错误。
正如计算机紧急响应小组(CERT)周二详细描述的那样(https://www.kb.cert.org/vuls/id/631579),这个名为CVE-2018-8897的漏洞似乎是由微软,苹果和其他公司制作的。该公司的开发人员对英特尔和AMD处理器如何处理特定的特殊异常产生了误解。
实际上,CERT特别指出:“这个错误似乎是由于开发人员错误解释现有文档。”换句话说,程序员误解了英特尔和AMD的手册,这可能不太清楚。
言归正传。这个问题的核心是POP SS指令,它从正在运行的程序的堆栈中取一个值来选择堆栈段并将该值放入CPU的堆栈选择器寄存器中。这与现代操作系统很大程度上忽略的内存分段完全相关,您可能忽略了它。 POP SS指令由CPU专门处理,因此如果指令在执行时被中断,则堆栈不处于不一致状态。
应用程序可以为POP SS设置调试断点,以从堆栈中获取堆栈选择器的内存位置。也就是说,当应用程序使用POP SS时,一旦处理器触及内存的特定部分以获取堆栈选择器,它就会生成特殊异常。
现在,问题的关键在于。 POP SS指令后面的指令必须是触发中断的INT指令。用户程序有时会使用软件生成的这些中断来激活内核,以便内核可以执行运行进程的任务,例如打开文件。
在Intel和AMD机器上,遵循POP SS的软件生成的中断指令会导致处理器进入内核的中断处理程序。然后,触发调试异常,因为POP SS导致异常被延迟。
操作系统设计者没有想到这一点。在阅读了英特尔的x86-64手册后,他们得出结论,处理程序最初是不可中断的。现在需要在中断处理程序的早期阶段处理意外的调试异常。如果执行指令POP SS,则调试寄存器在访问堆栈位置时设置为断开,下一条指令再次为INT N,然后在进入中断门后触发等待#DB,就像大多数成功一样分支指令。就是这样。操作系统开发人员假设从中断门语义,而不是不可屏蔽中断或可能的机器检查异常授予不间断状态。这可能导致操作系统管理程序软件的开发,该软件最初使用非特权软件选择的状态信息错误地认为这些影响。
这是严重的安全漏洞,也是操作系统开发人员的主要疏忽。原因在于描述POP SS指令的文档及其与中断门语义的相互关系尚不清楚,甚至可能不全面。
因此,在Intel系统上,用户的应用程序可以控制中断处理程序中的特殊指针寄存器GSBASE;在AMD系统上,用户应用程序可以控制GSBASE和堆栈指针寄存器。这可以用来崩溃内核(让内核触摸未映射的内存),提取受保护的内核内存的一部分,或者篡改内部结构以破坏系统或操纵其操作。
我们相信任何利用循环的尝试都更有可能导致内核崩溃甚至造成任何严重损害。但就像Meltdown这样的漏洞而言,这让业界有点尴尬;出于安全原因需要修补它。
有关此问题的FreeBSD安全公告将进一步说明。操作系统开发人员写道:“在x86架构系统中,堆栈由堆栈段和堆栈指针的组合表示。两者必须同步以确保正确操作。与操作堆栈段相关的指令具有特殊处理。机制与堆栈指针的变化一致。“
MOV SS和POP SS指令禁用调试异常,直到下一条指令的指令边界。如果指令是系统调用或将控制转移到操作系统的类似指令,则在内核环境中处理调试异常。而不是在用户环境中处理它。“
结果是什么? “授权的本地攻击者可能能够读取内核内存中的敏感数据,控制低级操作系统功能,甚至可能导致系统崩溃。”
根据微软的内核安全公告(https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8897),尝试在Windows上利用此漏洞的想法意味着“先攻击者”您必须登录系统。然后,攻击者运行一个特制的应用程序来控制受影响的系统。“除非您运行完全受信任的代码,否则这不是一个非常不可能的场景。
Red Hat已准备好发布补丁,Ubuntu和Apple MacOS也是如此。
早在2018年3月23日,Linux内核也得到了修复。版本4.15.14,4.14.11,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架构。现在,英特尔已经更新了手册,以阐明堆栈选择器指令的处理机制;读者应该赶快补丁。