其他操作系统将需要更新,性能会因此受到影响。TPU称,亚马逊、微软和谷歌是三个受影响最深的云计算厂商,如果漏洞被利用,那么在同一物理空间的虚拟用户A可以任意访问到另一个虚拟用户B的数据,包括受保护的密码、应用程序密匙等。
英特尔处理器芯片爆出了一个根本性的设计缺陷,已迫使业界大刀阔斧地重新设计Linux内核和Windows内核,旨在消除这个芯片层面的安全缺陷。
广大程序员正竞相全面改动开源Linux内核的虚拟内存系统。与此同时,预计微软会在即将到来的周二补丁日(Patch Tuesday)公开宣布对其Windows操作系统所作的必要改动:这些更新已发给在去年11月和12月运行快速更新通道(fast-ring)的Windows Insider版本的beta测试人员。
至关重要的是,针对Linux和Windows的这些更新将会给英特尔产品的性能带来影响。实际影响仍在测试当中,不过我们估计性能大概会因此降低5%到30%,这取决于具体的任务和处理器型号。最近面市的英特尔芯片拥有PCID等功能特性,可以缓解性能受影响这个问题。
类似的操作系统(比如苹果的64位macOS)同样需要更新;这个缺陷存在于英特尔x86硬件中,微代码更新似乎解决不了这个缺陷。必须在操作系统层面用软件来加以修复,或者去购买没有这个设计失误的新处理器。
关于英特尔芯片内部这个漏洞的细节秘而不宣:要求对这些细节保密的禁令会在这个月初解除,可能会在下周微软的周二补丁日前后。的确,针对Linux内核的补丁可供所有人查看,但是源代码中的注释已经过编辑,有意对这个问题模糊化处理。
然而,这个缺陷的一些细节已浮出了水面,下面是我们掌握的信息。
影响
据悉,该缺陷存在于过去十年生产的现代英特尔处理器中。它让普通的用户程序(从数据库应用软件到互联网浏览器中的JavaScript)在一定程度上得以发现受保护内核内存里面的数据。
解决方法就是,使用所谓的内核页表隔离(KPTI)功能,将内核的内存与用户进程完全分离开来。Linux内核开发团队一度考虑过Forcefully Unmap Complete Kernel With Interrupt Trampolines(又名FUCKWIT),让你了解这个问题对开发人员来说有多烦人。
只要运行中的程序需要执行任何有用的操作,比如写入到文件或建立网络连接,它就要暂时将处理器的控制权交给内核以便执行任务。为了尽可能快速而高效地从用户模式切换到内核模式,再切换回到用户模式,内核存在于所有进程的虚拟内存地址空间中,不过这些程序看不见内核。需要内核时,程序进行系统调用,处理器切换到内核模式,进入内核。完成后,CPU被告知切换回到用户模式,重新进入进程。在用户模式下,内核的代码和数据依然看不见,但存在于进程的页表中。
不妨把内核想象成坐在云上的上帝,俯视地球。上帝就在那里,芸芸众生都看不到它,但他们可以向上帝祈祷。
这些KPTI补丁将内核移到一个完全分离开来的地址空间,那样不仅运行中的进程看不见它,它甚至根本就不在那里。实际上,不应该需要这个,但英特尔芯片中存在的缺陷显然让内核访问保护机制可以被人以某种方式绕过。
这种分离的缺点在于,针对每次系统调用和来自硬件的每次中断,不断地在两个独立的地址空间之间来回切换,这从时间方面来看开销相当大。这种上下文切换不会瞬间发生,并迫使处理器倒出缓存数据,并从内存重新装入信息。这就增加了内核的开销,减慢了计算机的运行速度。
因此,你那搭载英特尔芯片的机器运行起来会变慢。
这个安全漏洞会如何被滥用?
轻则,恶意软件和黑客可能会钻这个漏洞的空子,更容易利用其他的安全漏洞。
重则,程序和登录的用户可能会滥用这个漏洞,读取内核内存里面的数据。就一句话,这可不是好事。内核的内存空间隐藏起来,用户进程和程序看不见,因为它含有各种各样的秘密信息,比如密码、登录密钥、来自磁盘的缓存文件等等。设想一下,如果浏览器中运行的一段JavaScript或者在共享的公共云服务器上运行的恶意软件能够嗅探内核保护的敏感数据,造成的后果就会不堪设想。
具体来说,在最理想的情况下,有人可能利用这个缺陷挫败KASLR:内核地址空间布局随机化。诸多操作系统使用这种防御机制,将内核组件放置在虚拟内存中的随机位置中。这种机制可以挫败企图滥用内核中其他缺陷的阴谋:漏洞代码(尤其是面向返回的编程漏洞,https://blog.skullsecurity.org/2013/ropasaurusrex-a-primer-on-return-oriented-programming)通常依赖于重复使用放在内存中已知位置的计算机指令。
如果你将内核代码随机放置在内存中,攻击者就找不到全面破坏系统所需要的内部部件或组件。有人可能利用这个处理器漏洞,搞清楚内存中内核如何确定数据和代码的位置,因而需要快速地推出软件补丁。
然而,英特尔芯片中的这个漏洞可能比上述的漏洞缓解路过(mitigation bypass)还要糟糕。AMD在圣诞节发给Linux内核邮件列表的电子邮件(https://lkml.org/lkml/2017/12/27/2)中表示,AMD处理器不受影响。不过,这封邮件的措辞还是泄露了秘密,表明底层到底出了什么岔子:
AMD处理器并不受到内核页表隔离功能防御的攻击类型的影响。AMD微架构不允许在特权级别较低的模式下运行时访问特权级别较高的数据的内存引用,包括推测性引用(speculative reference);如果出现这种访问,就会导致页面错误。
这里的关键词是“推测性”。像英特尔处理器这些现代处理器执行推测性执行。为了保持其内部管道塞有等待执行的指令,CPU内核会尽力猜测接下来要运行的代码,取出代码,然后执行代码。
从AMD的软件工程师汤姆•兰达基(Tom Lendacky)在上面给出的建议可以看出,英特尔的CPU可能在没有执行安全检查的情况下推测性执行代码。似乎有可能以这种方式来设计软件,以便处理器开始执行通常会被阻止的指令(比如从用户模式读取内核内存的数据),然后在特权级别检查进行之前完成该指令。
那将允许ring-3级别的用户代码可以读取ring-0级别的内核数据。而那不是好事。
这个漏洞的具体情况还有待证实,不过考虑这一点:对Linux和Windows所作的改动意义重大,正迅速部署到位。这表明这个漏洞比KASLR旁路来得严重。
此外,对Linux上独立的内核空间和用户地址空间加以更新离不开一组名为KAISER补丁的修复程序,这些修复程序是由奥地利格拉茨技术大学(Graz University of Technology)的研究人员开发而成的。这些研究人员发现(https://gruss.cc/files/kaiser.pdf),只要针对CPU的虚拟内存系统发动旁路攻击(side-channel attack),从内核中提取内存布局信息,就可以挫败KASLR。该研究团队建议分离内核空间和用户空间,防止这种信息泄露。安德斯•福戈(Anders Fogh)审核了他们的研究工作,他在去年7月撰写了这篇饶有趣味的博文(https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/)。
那篇文章描述了他试图通过钻推测性执行的空子,从用户模式读取内核内存里面的数据。虽然福戈无法给出任何切实可行的概念证明代码,不过他特别指出:
我的结果表明,尽管违反了内核模式和用户模式之间的分离,但推测性执行确实继续进行。
KAISER这项工作似乎与福戈的研究有关;除了设计一种通过钻虚拟内存布局的空子来挫败KASLR的实用方法外,该团队还证明了福戈是对的,那就是可以钻英特尔x86芯片上的推测性执行的空子,访问内核内存里面的数据。
共享系统
一位博客名为Python Sweetness的软件开发人员周一发表了一篇竞相转载和转推的文章,他在文中表示,这个缺陷会影响各大云计算环境,包括亚马逊EC2、微软Azure和谷歌计算引擎。
目前一个被下禁令的安全缺陷在影响显然所有实现虚拟内存的现代英特尔CPU架构,需要改动硬件才能彻底解决问题。外面正在开展紧急开发软件缓解措施的工作,这方面的成果最近进入到了Linux内核;去年11月,类似的缓解措施开始出现在NT内核中。在最糟糕的情况下,软件修复程序会导致典型的工作负载出现大幅减速。
有人暗示,这个攻击影响常见的虚拟化环境,包括亚马逊EC2和谷歌计算引擎……
微软的Azure云不光运行Windows,还运行大量Linux。Azure云会在1月10日进行维护和重启,大概会推出上述修复程序。
亚马逊网络服务(AWS)也通过电子邮件警告客户,预计本周五发布重大的安全更新,但没有透露细节。
虚拟机管理程序爆出严重漏洞(可能涉及Xen)的传闻在2017年年底甚嚣尘上。这个硬件缺陷很可能就是那个传闻中的漏洞:可以通过这个内核内存访问缺陷,攻击虚拟机管理程序,因此需要打上补丁,迫使大批启动来宾虚拟机。
英特尔发言人没有出面发表评论。
本文链接:http://www.yunweipai.com/24811.html
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/industrynews/53006.html