英特尔遭遇CPU级RootKit,目前无药可医 2009-03-19 来源：cnbeta 作者：Ben
cnBeta news
感谢Ben的翻译投递:
Intel CPU 缓存被暴漏洞,研究报告与 RootKit利用代码即将出炉。
"3月19日,我们将就Intel CPU 的缓存机制漏洞,公布一份报告及漏洞利用。相关攻击可以在目前大部分IntelCPU的主板上从Ring0提权至SMM。Rafal在几个小时内就做出了一份漏洞利用代码。" Joanna女强人在博客中写道。
本次漏洞利用的致命之处,在于它能将自身隐藏在SMM空间中,SMM权限高于VMM,设计上不受任何操作系统控制、关闭或禁用。实际应用中唯一能确认SMM空间中运行代码的方法只有物理性的分离计算机固件。由于SMM优先于任何系统调用,任何操作系统都无法控制或读取SMM,使得SMM RootKit有超强的隐匿性。
其厉害程度与之前的BluePill相似,但比VMM攻击涉及到系统的更深层面。而 SMM自386时代就出现在Intel CPU中。
Joanna 和 Loic 这次将发布从未公布过的Intel缓冲HACK。
它不但可以控制SMM空间还能运行其新型RootKit,控制计算机。新的 RootKit 甚至有能力连接服务器更新代码,储存数据。运行于操作系统中的任何软件都将无法检测此类利用。
据 Joanna 说,Intel员工,对Intel的此类 CPU 缓存及SMM漏洞利用的署名讨论可以追溯到2005年。她与Loic于去年10月已经向Intel正式提交过报告。Intel将问题通知了CERT并将其归为漏洞VU#127284号。现在Intel已经知道漏洞的存在好多年了,却没有做出应有的修正。无奈,安全专家们别无选择,只能公布他们的发现。如果此漏洞利用真的已经存在数年,那么一定早已有人开始利用它。正如Joanna所说"漏洞就在那里,如果足够长的时间内没人理会,几乎可以肯定,怀着各种意图的人们将会发现它并将之利用,只是迟早的事。所以请不要责怪研究人员,他们发现并公布问题 - 他们实际上是为了帮助我们的社会。"
报告将于19号在此发布：
http://theinvisiblethings.blogspot.com/2009/03/independent-attack-discoveries.html之前的 SMM 利用原理：
http://wwww.networkworld.com/news/2008/050908-black-hat-hackers-find-a.html?page=1来源（NetworkWorld）
http://www.networkworld.com/community/node/39825另附论坛jefffire的转帖
这是以前的一篇相关文章：
其实SMM是早在97年就有的东西,我跟这个东西也算是有点渊源,之前在实验室做过一些关于这个的研究，但是远没有到rootkit的方向.之后在逛网站的时候发现一篇5.12时候的新闻:Researchers dig into x86 chips for stealthier rootkits,然后才重新回头去看了这个东西,也隔天就写了篇分析.不过功力尚浅,很多东西在Win32平台到现在我实验着还是有问题的.
SMM类似ICE,ICE是一种硬件调试机制,也是深入到CPU级别的最根本的调试,但是ICE在Intel公司对CPU的改革过程中变成了现在的Branch Trace(tr12)[1],而SMM也继承ICE的实现方式(但并不是直接的"复制")独立成为新的机制,主要处理ACPI,详细的介绍看后面的[注][2].AMD 稍微显得逊色一些,之前的CPU版本可以利用XX软指令去改DR7,也就是说基本是ICE的直接复制.Intel也显示出优越性,一来Intel的SMM 是不支持调试触发的,因为Intel把SMM和ICE分开了,再者Intel的SMM也不支持微处理器的指令触发,只能由硬件中断(CPU,ACPI)来引发.我也提到过一个很好的物理方法,就是用信号发生器和频率源去接芯片引脚... :)
由于太过于依赖硬件,CPU的支持很大程度上决定了SMM的实现方式,而且不同的主板公司(主要是BIOS)也可以实现不同的SMI处理例程,在之前(2008.5.12)我个人觉得要做成 rootkit还是有不少问题的.由于SMM的特殊性:CPU不管是怎么切换,由SMI进入SMM或者由RSM切回保护模式,都是悄然无声的,OS是"不知道"的.SMI handler是在POST的时候安装到SMRAM里的.要想rootkit,肯定要想办法遛进SMM.当时也很怀疑Sparks是不是要在类BSD系统上演示,因为相对来说,WIN32更加的困难,有很多的限制,一方面和硬件关联太多,一方面又要PIO操作权限又要内存操作权限,不好处理.
要在正常模式下做成rootkit,首先就要保证控制寄存器位的置位(D_OPEN),因为如果D_CLK位打上去的话,只读了,就失效了.想办法进 SMRAM?HSEG(正常系统模式下,0xa0000-0xbffff这段内存是给某些显卡的)看起来remap也不那么简单,位被限制的很死,而且一旦到了Above段,更是一碰就挂...那就是想办法更改SMI Handler了,不过这个比较好检测,AV只要定时检查就能知道是不是有handler被修改了.要不然就是通过BIOS,那就更是多此一举,那么多驱动要BIOS CALL,可以修改BISO直接就搞了[思路上就是动比如bus0-dev1-func0-0x30/33这几个寄存器,PCI配置头它们指示的是 expansion rom,会被map到比如0xC0000，刷进去，然后想办法hook int,10号或者其他号,10号想必大家都清楚,VGA小端口会调用比如Ke386CallBios交回控制权.这里还涉及一些VM86的东西,公开的未公开的.推荐一下VBEMP x86 Project :) 做为副产品,你可以从里面得到关于以上东西的一些灵感.至于Re-flash,这个就不多说了,IO方法很多],但是通过BIOS也可以给SMM-RK做个引子.
不过既然Sparks要在BH上演示,也只好要拭目以待,可惜的是,她在BH上的演讲并没有什么让我觉得为之一亮的地方.因为在BH之前PHRACK爆出的一篇文章里把基本的内容都含盖了:System Management Mode Hack .
Paper 里提到触发SMI是通过存取PCI配置寄存器(其实可以衍生出不少方法,比如APM.),类BSD系统上的.PIO 0xCF8-0xCFF,如果是新的PCI-Express MMIO更简单.Paper里只是简单提了下Code relocation,其实这个特性很强大.你可以修改state save map里的SMMBASE值,完成一些隐蔽工作.但是这里可能会有点问题,因为我在这里挂起了很多次.就是如果你需要装进DS,需要在SMM handler里自己从state save map里读出descriptor cache结构体的里CS段的地址值,shr 4后给DS,这样才是指向了重定位后的SMMBASE.其他的值也是一样,你可以修改CRx,CS,EIP,EFLAGS以及CPL(SS.DPL),来实现模式切换(这个很有价值). 关于中断,SMM处理中断并不像Intel手册说的.先看看paper里的2.4.2 - SMM Details这一小节,其实中断确实会被屏蔽,但是paper里的"To enable that is needed to issue the IRET/IRETD instructions" 是不对的, 至少我没成功,我的方法是设置硬件中断例程[timer kick]. 后面又提到code relocation后会出现很多莫名其妙的问题,其实这个和前里提到的一样, CS:IP也需要你手动修改,取SMRAM里的SS,CS值,shr 4然后push入栈,取esp,retf就可以了.
请问这东西是否对我们用户造成危害..........................
用户系统信息：Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; CIBA; 360SE)
