|
Intel处理器存在芯片级安全漏洞 图 一、概要Intel处理器芯片基础架构中存在一个非常严重规划缺陷，Linux以及Win不得不大幅改动、重新规划内核，才能搞定这个芯片级安全漏洞。 受芯片级安全漏洞的影响，程序员们正在抓紧时间修补开源的Linux内核虚拟内存系统。与此同时，微软估计将在下一个周二补丁日（Patch Tuesday）发布适配Win操作系统的补丁，这些补丁会优先分发给加入Win Insider计划的beta版测验用户（具体为在11月份到12月份之间发布的系统）。 非常关键的一点在于，Linux以及Win引入的这些更新会大幅降低英特尔产品的性能。具体的影响程度仍在评估中，但我们估计整体性能会出现5%~30%的下降，具体数值与实际的任务及处理器型号有关。最新的Intel产品包含一些功能特点（如PCID），一定程度上可以缓解这种性能损耗，但具体效果因人而异。 Twitter上@TheRegister发布了一则推文，介绍了在引入KPTI（Kernel Page Table Isolation，内核页表隔离）修复措施的情况下，PostgreSQL中SELECT语句性能的受影响程度。研究表明，性能下降幅度最少时为17%，最差时可达23%。 其他相似的操作系统（如Apple的64位macOS）也需要更新，由于该缺陷位于Intel x86-64硬件中，并且微码（microcode）更新并不能搞定这个问题，因此只有操作系统层的软件才能修复这个漏洞，或者用户也可以选择购买一个不存在规划缺陷的新版的处理器。 Intel仍未公布这个漏洞的具体细节，可能是为了配合微软下周二发布的补丁。另一方面，Linux内核的修复代码已经公布，每个人都可以查看修复代码，但源码中的注释已被处理过，以掩盖相关信息。 现在该缺陷已公布了部分细节，我们会在本文中介绍这些内容。 二、影响范围据了解，过去十年中生产的Intel处理器都存在这个漏洞。普通用户程序（如数据库程序、浏览器中的JavaScript等）可以利用该漏洞在一定程度上获得受保护内核内存区域的布局结构或数据内容。 KPTI（Kernel Page Table Isolation，内核页表隔离）这种修复措施可以完全隔离内核内存或者用户进程。Linux内核团队曾经将KPTI称之为FUCKWIT（Forcefully Unmap Complete Kernel With Interrupt Trampolines），从这个名字上你就可以了解该漏洞给开发者带来多么大的苦恼。 当运行中的程序需要处理某些关键任务时（比如写文件或者打开网络连接），就需要暂时将处理器的控制权交给内核来处理该任务。为了让用户模式与内核模式的交互过程尽可能快速高效，内核实际上会存在于所有进程的虚拟内存地址空间中，但同时也对这些程序透明。当需要运用内核时，程序就会执行系统调用，处理器会切换至内核模式，进入内核。任务完成后，处理器需要切换回用户模式，重新进入进程中。在用户模式下，内核的代码及数据依然处于不可见状态，但仍位于进程的页表中。 打个比方，我们可以将内核想象成坐在云端的上帝，正在俯瞰地球。上帝就在那里，凡人或凡物无法看到他/她，但依然可以向其祈祷。 KPTI补丁可以将内核转移到完全隔离的地址空间中，因此正在运行的进程无法看到它，因为内核根本就不在原来的位置上。实话实说，这么处理其实不是很必要，但因为Intel芯片中存在缺陷，导致运用某些方式可以绕过内核访问保护机制，因此还是需要采取这种措施。 这种隔离机制存在不够之处，每次出现系统调用以及硬件中断时，需要在两个隔离的地址空间上来回切换，这种切换过程比较昂贵，需要耗费一些时间。上下文切换不会立即发生，会强迫处理器转储已缓存的数据、重新从内存中加载相关信息。这样一来就增加了内核的开销，减慢计算机处理速度。 因此，如果你运用了搭载Intel处理器的主机，那么运行速度就会受到影响。 三、如何滥用最好的情况下，恶意软件以及黑客可以利用该漏洞使其他安全漏洞利用起来更加方便。 最差的情况下，程序以及已登录用户可以滥用这个漏洞，读取内核内存数据。此时事情就变得比较糟糕。内核的内存空间正常情况下应该对用户进程及程序透明，因为该空间中可能包含各种各样的奥秘信息，如密码、登录秘钥、从磁盘中缓存的文件等等。想想一下，如果浏览器中运行的某段JavaScript代码或者共享公共云服务器上运行的某款恶意软件可以嗅探敏感的内核保护数据，这是一件多么可怕的事情。 更具体一点，就最好的情况而言，攻击者有可能会滥用这个漏洞来绕过KASLR（kernel address space layout randomization，内核地址空间布局随机化）。许多操作系统会运用这种防御机制来将内核组件布置在随机化的虚拟内存中。这种机制可以阻止攻击者滥用内核中的其他缺陷，比如，漏洞利用代码（尤其是ROP利用代码）需要复用内存中已知的计算机指令地址才能成功发起攻击。 如果随机化内核代码在内存中的位置，那么利用代码就无法找到所需的内部代码片段（gadget），因此也就无法顺利攻破系统。然而，利用这个处理器漏洞，攻击者可能会找到内核代码及数据在内存中的具体位置，从而加大软件修复过程的难度。 然而，Intel芯片中的这个漏洞造成的后果可能会比上述场景更加严峻。在圣诞节期间，AMD曾给Linux内核邮件列表发过一封电子邮件，邮件中提到AMD不受此漏洞影响。该邮件表明，游戏使用并不会受到这个底层漏洞影响。
上面这段话中的一个关健词为“推测型（speculative）”。包括Intel在内的现代处理器都会运用推测型执行机制。为了保证处理器的内部管道中尽可能多地填充需要执行的指令，处理器核心会尽力去猜测接下来需要执行哪段代码，然后再去获得并执行相应代码。 从AMD软件工程师Tom Lendacky发表的上述内容来看，Intel 处理器所采用的推测型代码执行机制可能没有执行安全检查。貌似攻击者可以精心规划一个软件，这个软件可以先让处理器执行通常会被阻止的那些指令（如从用户模式下读取内核内存），然后在权限级别检查过程之前完成指令执行。 这样一来，ring-3级别的用户代码就可以读取ring-0级别的内核数据，这并不是一件有趣的事情。 具体的漏洞细节依旧没有公布，我们现在关于该漏洞的严重程度依旧只是一些推断（但足以反映很多问题）。由于Linux以及Win在面对该漏洞时需要大幅改动，并且都在加班加点快速推出相应补丁，这表明该漏洞会造成比绕过KASLR更为严重的后果。 此外，Linux在一系列补丁的基础上将内核及用户地址空间隔离开，这些补丁统称为KAISER补丁集，由奥地利格拉茨技术大学（Graz University of Technology）的eggheads团队发布。相关研究资料（PDF）表明，攻击者可以通过旁路攻击（side-channel attack）处理器的虚拟内存系统，提取出内核的内存布局信息，从而绕过KASLR保护机制。该团队提出系统可以隔离内核及用户空间，以阻止这类信息泄露，他们的研究成果是此次修复程序的基础。 Anders Fogh分析了该团队的研究成果，并在7月份时撰写了一篇研究博文。那篇文章中，作者描述了如何滥用推测执行机制，从用户模式下读取内核内存。虽然Fogh没有公布任何PoC代码，但他提到过这么一句话：
看起来KAISER的研究成果与Fogh的研究存在交集，由于该团队演示了如何滥用虚拟内存布局来绕过KASLR机制，某种程度上也证实了Fogh的结论，那就是攻击者可以利用Intel x86芯片上的推测执行机制来访问内核内存。 四、共享平台同样受影响某位软件开发者周一时在Python Sweetness博客上表示，这个漏洞会影响许多大牌云计算平台，如Amazon EC2、Microsoft Azure以及Google Compute Engine，该文章在推特上被大量共享及转发。其中有这样一段话：
微软的Azure云上运行了许多Linux以及Win系统，将于1月10大批量进行维护及重新启动，可能是为了及时打上上述补丁程序。 Amazon Web服务也通过邮件告知客户周五时会发布一个重大安全更新，但没有涉及具体细节。 之前有传言说Xen虚拟机管理程序（hypervisor）存在严重漏洞，具体细节会在2017年末公布。这个硬件漏洞可能就是传说中的那个漏洞：攻击者可以通过违规的内核内存访问攻击hypervisor，因此厂商需要进行修复，大范围重新启动虚拟机。 Intel发言人暂时未发表评论。 顺便说一下：貌似64位的ARM Linux内核也会打上KAISER补丁集，完全隔离内核及用户空间，以阻止攻击者绕过KASLR。 |
/1 
