除Intel之外AMD和ARM也中招了:谷歌ProjectZero小组博客披露新CPU漏洞Spectre,波及市面所有品牌CPU,原理上无法通过软件修复

这一次由Intel服务器CPU产品诱发的安全事故现在规模正式扩大,确认波及到ARM和AMD,也就是说,近二十年来生产的几乎一切手机、电脑、云计算产品都在风险之列。安全人员将两个新的漏洞命名为Meltdown(熔断)和Spectre(幽灵),前者允许低权限、用户级别的应用程序“越界”访问系统级的内存,从而造成数据泄露。

现在发现的bug有两个

1.叫做Meltdown(崩溃),目前只存在于intel的处理器和部分arm处理器,amd不受影响

2.叫做Spectre(幽灵),存在于一切有乱序执行的现代处理器架构里面,当然包括amd。乱序执行已经是现代处理器设计不可或缺的一个组件了。但是这个bug需要在宿主的电脑里面主动运行,无法形成有效的攻击,除非你下载和安装攻击者的代码,还要在同一个进程里面才能获取到想要的信息。这个bug,从另一个方面,对于浏览器影响巨大,因为javascript的存在,目前不知道这个能怎么修复,hacker news有人猜想是在jit代码里面安插额外指令来强迫顺序执行,这样会影响性能,而且并不能完全消除bug,只能让bug的出现变得更困难。

mozilla跟进了,spectre确定能窃取其他页面的信息,目前的应对方案是减少时间测量的精度。

虽然AMD称基于谷歌研究的三种攻击方式,自己的处理器基本免疫。但Spectre(幽灵)漏洞的联合发现者Daniel Gruss(奥地利格拉茨技术大学)称,他基于AMD处理器的Spectre代码攻击模拟相当成功,绝不能低估。讲道理,农企这次又在胡说八道了,这种乱序执行构架上的问题OS和软件能彻底解决的话,农企干脆去做软件得了还做什么硬件。。。。

从原理上来说根本没法彻底修复,大概只能是各个软件自己调整刷新页面时钟来降低被破解的风险吧

现在看来 intel 的可能影响更大一些,amd 的影响的看法现在可能还有分歧(不过听起来没 intel 的那么严重)。
intel 和 amd 都还没有回应 google project zero 说的问题,arm 回应了,说他们确定他们的很多现代的高性能处理器有这个问题,然后他们现在提供了一些方案之类的。
arm公布表格有4个变种,从a9-a75,变种1-2都受到了影响,变种3a有几款有影响。

看了下,amd 官方也发表声明了。列了个表,说3种攻击,第一种可以通过软件和os解决,性能的影响可以忽略。第二种说因为amd的架构不同,所以第二种的影响接近0,他们还没有发现成功的例子。第三种他们说因为架构的不同,他们不受这个影响。(这里的三种的顺序可能和其他的不一样或者一样,申明里没说明)amd说的第三种是指Meltdown,然后一二是指Spectre的两种。

看arm给出的Spectre解决方法,就是jit时候直接把有问题的特征代码抓出来特别处理,估计适用也就是JAVA和JS,已经二进制发行的应该是无解。

Spectre的漏洞的攻击原理是利用了处理器的分支预测和投机推测执行

大致原理:

1.处理器会在一些条件分枝,比如if else不成立的情况下,先执行其中的代码,如果事后发现条件不成立,再把结果丢弃

2.这个攻击就是利用这个特性,在处理弃来不及判断分枝是否的合法的情况下执行了分枝的内部代码(这部分代码是攻击者设计好的,目的是读取越界的内存的内容),结果是造成一部分数据被l1 cache给缓存起来,然后之后通过对于这部分数据的访问时间的差别,来推测到底是那一部分数据被缓存了,然后再由此逆向出越界读取的内存的内容。

除非从硬件上消除这种行为,也就是分支预测+推测执行会在l1 cache留下副作用的行为,这个漏洞应该是无法被软件fix的。

这个叫做spectre的bug应该会影响所有的现行处理器,有人已经设计出来一段javascript来来泄漏宿主内存的内容了,而且没法用软件fix。

===================

Meltdown相关:

此漏洞最早由某404公司研究机构发现,目前还不清楚有没有人利用早在17年中就被发现了,各大芯片和OS厂互相通气一起研究办法 因为底层的硬件的设计漏洞 很难修复了 只能靠os方面打补丁突破口就是楼上各位所说的speculative execution , 用的某种side channel attack.发现者估计也是硬件+架构+os大牛了…总之能获取内核的数据 speculative execution算是很普遍的优化方式,基本现代复杂一点的核都会用到,intel 就更不用说了. 修复完加上限制后会有较大的影响. 但具体怎样无从得知…新闻上那个30%有标题党的嫌疑Ps:这回修复amd也有帮忙 基本相关公司都出手帮忙了 intel amd MS Apple 等等 毕竟利益相关…

首先要明确的是:1)这个漏洞不是去年说的Intel ME的漏洞;2)这个漏洞不是很多答主说的依靠时间推测内核加载地址的问题。这是一个新爆出的漏洞,虽然看起来不是1月2号才暴露出来。因为Linux和Windows早在去年11月份左右就有动作开始修补了。下面是科普时间:首先我们需要知道,以前常见的虚拟内存结构是怎样的。以32位Linux为例,我们知道2^32 Bytes = 4GB,从应用程序的眼中来看,我拥有4个G的内存。但是,这4个G的内存并不完全属于应用程序——高地址那边的1GB大小的映射是属于内核的。比如,假设内核有一段代码在虚拟地址0xCCCCCCCC这个位置上,应用程序也是无法直接调用的。换句话说,虽然这些地址普通程序不能访问,但内核程序、内核栈等确实映射在这了。看起来一切正常。接下来,假设我们发现了一个内核漏洞,这个漏洞允许程序调用任意内核级的代码——也就是说,应用程序通过这个漏洞可以调用内核中0xCCCCCCCC地址的程序了,进而对系统造成危害。那么如何减轻发现内核漏洞之后的危害呢?毕竟,有代码的地方就会有bug。大佬们决定采用一种随机的方法:你不是要调用0xCCCCCCCC这块的代码吗?那我每次启动的时候,把内核映射到一个随机的地址上就好了嘛,比如这段代码这次启动的时候它在0xCCCC0000,下次启动它就变成了0xCCCC8888,让人摸不着头脑。这种机制就叫KASLR。它随机化内核在虚拟空间中的地址,只有内核自己知道我在哪,别人休想知道。所以说,KASLR不是“修补”漏洞,而是提高了利用漏洞的成本——最好的情况是,虽然有人发现了漏洞,但却难以利用。但是,魔高一尺道高一丈。另一位大佬说,你这太弱了。我用一种方法,能探测出你究竟随机到哪去了。这就是很多答主说的Time Based Attack。因为放代码的地址和没放代码的地址,在某些操作下时间长短不一样。因此,这种Attack不是真正的漏洞攻击,但他让KASLR机制失效了。如果有人发现了可利用的内核漏洞后,就可以用这种方式绕过KASLR。大佬还说了,虽然KASLR不好使了,但我的新方法好使啊。这个新方法就是KAISER——内核除了让应用程序知道必要的信息外,不再在应用程序的眼中“可见”。但是代价也是有的,就是性能会有所下降。好了,下面到了今天主角登场的时间了。这次的CPU漏洞,能够使得应用程序访问任意虚拟地址——包括映射到应用程序空间中的内核内存(即新闻标题中的“Kernel Memory Leaking”,内核内存泄露)。这就相当于我们刚才说的“内核漏洞”(虽然这是CPU的bug),但是这个漏洞可不好修。所以只能阻止这个漏洞的利用条件了——用KAISER机制,让你根本访问不到内核中的东西,把内核从应用程序的眼中“隐藏”。虽然降低了一些性能,但也总比被搞事情强。Ps. 根据一些文章,目前这项机制在Linux中改名为了“KPTI”,即内核页表隔离。

预测技术,Intel成也萧何败也萧何为了提高处理效率,当代处理器内嵌有预测技术:通过预测下一条指令,处理器可以填满内部流水线,充分发挥运作效率。Intel的推测执行(Speculative Execution)技术是业界标杆水平,行业内所有公司都在向Intel靠拢,但是这个漏洞说明Intel的推测性执行在芯片内部的访存执行单元Load/Store Unit和重排序缓冲区ROB上存在安全检查漏洞,导致操作系统核心的安全保护出现问题,使得用户程序可以窥测内核数据,包括系统访问历史记录,密码等等隐私,同时会造成KASLR(Kernel Address Space Layout Randomization,内核位址空间布局随机化)的无效化,导致攻击者可以推断出内核地址,进而发动攻击控制控制整个系统,造成严重的安全风险。受影响用户包括服务器环境、PC环境和移动环境。在Linux的源代码和邮件列表中显示,一开始的补丁也囊括了AMD CPU,但是AMD公司的工程师主动进行了修正,声明AMD的处理器不受影响并且要求取消了对AMD的补丁,目前这个补丁仅在Intel CPU上生效。 操作系统厂商纷纷发布补丁尝试修复此漏洞,但补丁会对性能造成严重影响本次漏洞无法在芯片层面得到修复,修复只能在操作系统层面进行(或重新购买CPU)。微软预计本周四会推送补丁,且补丁已经包含在去年年底的Windows Insider版本中。苹果的MacOS也未能幸免,需要进行相应的修补工作。本次补丁的主要功能是通过KPTI(Kernel Page Table Isolation)完全分离系统内核与用户内存,让系统使用另外一个分区表,使得用户程序无法访问系统内核。但是,KPTI会导致CPU频繁地从内核模式切换到用户模式,引发耗时的TLB缓存刷新,拉低系统效能。根据初步测试,Intel CPU效能会降低5%-30%,相当于回退1~2代。举例来说,第八代的酷睿CPU打上补丁后的效能可能低于同档次的第七代的酷睿CPU。Intel善后花费巨大综合专家看法,我们认为,研发方面,Intel修复本漏洞需要组织工程师Review几十万行RTL源码来确认问题所在,而发现问题后的问题解决过程将耗费更多的人力物力:我们预计Intel至少需要花费几个月的时间才能提出可行的解决方案,并做完初步测试,而采用新方案的芯片的性能将会是一个未知数;商务方面,Intel需要安抚各大客户的情绪,特别是采购了大量Intel CPU的云厂商,以防新增订单向AMD的转移,同时,对于已有的服务器设备,Intel需要与厂商一起研发解决方案堵住漏洞;品牌形象方面,Intel的高端形象无疑会遭受重创,建立品牌认知将花费较长的时间。2016年,Intel花费了127亿美元用于研发。假设其中10%用于CPU研发,本次漏洞造成Intel CPU性能的回退至少给Intel带来了12.7亿美元的损失(相当于研发产生的性能提升被抹掉),而整体的善后成本在考虑修复成本、商务成本、品牌重建、市场竞争等因素后或将超过25亿美元。云厂商面临巨大压力,云服务成本或有较大提升本次的漏洞会影响所有的云厂商,包括但是不限于Amazon、Microsoft、Google等巨头。云厂商只要使用Intel CPU,就需要通过补丁进行系统加固。然而,由于云平台应用了大量的虚拟化技术,这些补丁比针对个人电脑的补丁更为复杂,由于云厂商的服务器拥有极高的数据吞吐,补丁对服务器系统效能的影响会比对PC更为严重。Microsoft Azure将于1月10日进行维护和重启,据称跟本漏洞有关;AWS也发送了通知邮件声称本周五将进行重大安全更新。让人担心的是,已经有迹象表明有黑客在利用本漏洞攻击云系统。我们认为短期来看,云厂商的服务成本或有较大提升。

4号8:45:https://meltdownattack.com

Paper出来了,确实跟猜的很接近

靠缓存计时旁路推断内容

不说了,错过几个逸

中午午休再来具体分析吧(躺平)

还得把分支预测器科普了,好多字啊不想码啊啊啊啊啊啊(。)

==============分割线==============

19:00在公交车上梳理一下

1. 这漏洞意味着什么

程序可以无视权限控制,随意读取本程序虚拟内存内的数据

由于Linux和Windows的内存模型设计(内核与程序共享一个虚拟地址空间,通过权限控制阻止程序访问内核),这意味着任何程序都可以读取内核,包括诸如加密文件系统的密钥之类的数据

2. 漏洞的来源是哪里

Intel的CPU

农企日常翻身(划掉)

臆测:照AMD在Linux邮件列表上的反应,很可能与Speculative execution这个CPU特性有关,可能是在这过程中忽略了访问控制而通过其它途径泄露了不可访问数据的相关信息,具体看下面原来的回答

3. 如何应对

KPTI/KAISER:把内核从程序的虚拟地址空间里移出去,只保留最最最基本的东西,需要用的时候再切换回来

4. 有什么影响

不采取应对措施意味着一个普通程序可以随便读你电脑上的东西

采取应对措施意味着每次使用操作系统的服务都需要切换一次,对系统性能产生负面影响

=============以下原文===============

从LKML上AMD的反馈来看估计和Speculative execution(不知道中文,反正就是CPU估计会运行什么指令就先跑起来的一个功能,对性能提升很有帮助)的时候会预先读取无权访问的内存有关

然后科普一点,现在的处理器基本上都是超标量乱序执行的,意味着:

CPU每个时钟周期可以执行超过1条的指令
CPU不一定会按照指令流的顺序执行指令,但是最终可见的值是不受这个重排序影响的

现在的CPU基本上是这么工作的:

指令解码:
将指令翻译成微代码(是,x86处理器基本上都已经是硬件级JIT引擎了……)
将微代码丢进执行队列
调度执行:
调度器检查队列中的微代码,依据现有资源和微代码间的依赖关系,选出可以执行的微代码
调度器将这些微代码(可能有多个)发送给相应的执行器执行
执行器将执行结果丢回调度器(结果、异常、状态位之类的)
调度器检查缓存里最旧的指令的微代码是否已经全部执行完毕,如果没有完成执行,回到第2.1步
将最旧的指令的微代码移出队列
结果提交:
按指令的执行结果更新架构状态(写入寄存器、产生中断等)
如果发生了需要特殊操作的事件(比如异常、中断等),清空整个流水线并按流程处理

注意除了3可以清空掉1、2之外,这三块基本上是互相独立工作的

如果我们访问了不能访问的内存,这个异常是在3.2这一步里引发的,此时整个流水线都会被清空

但!是!2.2这一步可能已经访问了这部分内存,只是因为3.2引发异常而丢弃了结果

所以说如果有办法能观测到2这一块对内存的使用情况的话……

比如这段汇编:

CLFLUSH [用户地址]
CLFLUSH [用户地址 + 1]
MOV AX, [内核地址]
AND AX, 1
MOV BL, [用户地址 + AX]

显然,在第3条就会发生异常。

但是,万一,万一在清空流水线前,调度执行阶段执行到了第5条会怎么样!

如果这个内核地址的最低位是0,那么我们会访问用户地址 ,但是如果是1的话,我们会访问用户地址+1

如果我们把这个地址放在缓存页的边界上 ,那么根据这个内核地址上最低位值的不同,被加载进缓存的页也会不同,后续访问两个页的延迟会存在区别

所以说……我们就能推断这个内核地址上的值了?

哦对,以上这段是确认不能用了我才发出来的(真要能用早三五年就被人报了好么)

估计这次的东西可能是类似的原因,调度执行阶段会忽略访问控制,以致在后续执行中可以通过其他间接方式观测/推测这个不可访问的值

如果是能直接读出来的话……Intel什么时候倒闭?

类似的手段早已用于对IOS设备的越狱。KSALR技术就是随机内核代码在内存中的位置,确保恶意程序“找不到”内核所处的内存,只有内核知道自己在哪,配合内存分页,确保内核代码的安全。最早的iOS越狱需要遍历内存找到内核的位置,所以早期都是不完美越狱,需要PC端辅助开机。然后猪队友来了:ARM的错误中断向量表(对ARM不了解,等评论区大佬指正),故意触发一个错误,特定的寄存器会指向出现错误处的内存,ARM这个二五仔把内核一卖,一万只铁骑直接重写内核部分的内存。这次INTEL的漏洞在于,虽然遍历内存不知道读的是什么,但是读取的速度不一样,那里是被保护的内核代码,那么速度就会被拖慢。再加上通过一个不为人知的手段,跳过对MMU的限制(没错,这部分的补丁没有注释,看不懂),想怎么读写内存就怎么读。INTEL这个二五仔。。。几十年前的PDP11都知道内核分页表和用户分页表分开,INTEL是在想什么啊。我仿佛可以看到全球最大的农业生产用具部门的女老板的笑容。加上前一段时间的ME事件。

这是一个根据CPU微架构实现来进行的一个旁通道攻击(side-channel attack)。目的是猜测一个地址是否被kernel使用。之前普遍的解决办法是Kernel ASLR,也就是在kernel使用的地址做随机化处理。

看了一下攻击原理 http://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf。用户空间对于一个指针的访问,是要经过硬件的MMU来进行mapping,并根据page所设置的属性来判断用户对改地址是否可以访问。user/kernel态的隔离就是通过页表上的属性来决定的。但是这样虽然可以保护地址不会被访问,但是intel的CPU设计是这样的:

当用户态访问一个kernel地址p的时候,有两种可能:

如果p所在的页表在TLB中存在,则查询TLB映射p这个地址的页表属性来决定是否可以访问
如果p在的页表TLB中不存在,则需要先进行TLB Table Walk,当页表被TLB cache住时候,再判断p所在页表的属性。

两种做法,存在一个TLB Table Walk的时间差。通过这个时间差的存在性,就可以猜测一个地址是否被kernel使用。这样,就相当于破坏了前面Kernel ASLR的作用。

而文中提到,这个攻击对AMD的处理器无效,the register的链接里面也提到AMD的做法是lower privileged的memory reference无法引起higher privileged的地址上的page fault。甚至连speculative reference都不可以。

ARM处理器是否收到这个影响,也要看微架构的实现上,是否导致了上面的这两种访问的时间差。

MIPS的架构上特点降低了这种攻击的可能性,因为kseg0/kseg1本身就是unmapped的,不经过TLB的访问。

镜像链接:谷歌镜像 | 亚马逊镜像

分类: 科技 标签:
  1. 匿名
    2018年1月4日10:45 | #1

    各大CPU厂商之间开始互撕了

  2. 匿名
    2018年1月4日12:14 | #2

    不经考验,不见真理。这是世间常态,也是世间真理。

    苏格拉底说未经检验的生活不值得活,弥尔顿说未经诱惑试炼的信仰非真正的信仰,这个无非是“技术”领域的又一小波折而已。

  3. 匿名
    2018年1月4日14:12 | #3

    可以预见的是pc等电子产品的销量会更大程度的减少

  4. mego
    2018年1月4日15:29 | #4

    连杀毒都不装的大有人在,安全对于大都数人其实没那么重要。

  5. 匿名
    2018年1月4日17:14 | #5

    mego :
    连杀毒都不装的大有人在,安全对于大都数人其实没那么重要。

    普通用户看看热闹。数据安全可是互联网企业的命根子

  6. 匿名
    2018年1月4日18:08 | #6

    @匿名
    在墙内装不装杀毒软件,对电脑信息的保密没有任何帮助,必竟现在没有多少人无聊的到把你电脑毒死,他们更需要的是你的个人信息,每天监视你的行为,收集起来就成了大数据….

  7. 2018年1月4日18:33 | #7

    所以这篇文章和你们这些屁民有什么关系?

  8. 匿名
    2018年1月5日01:33 | #8

    我是个十足的阴谋论者,没准淫特尔就是故意留下这么一个漏洞后门好让某些掌握这个漏洞的官方御用”骇客”可以随意进出使用淫特尔cpu的电脑,没准整个世界上所有使用淫特尔cpu的电脑早被掌握这个漏洞的官方御用”骇客”看光光了,根本就毫无隐私可言.

  9. 匿名
    2018年1月5日10:13 | #9

    哈哈哈哈哈哈哈哈哈哈!

    全球欢迎性能下降,从笔电到台机,从VPN到个人网站,从云计算到数据库,一起喜大普奔!

  10. 匿名
    2018年1月5日10:57 | #10

    不管怎么说,下次买电脑,肯定全AMD了

  11. 匿名
    2018年1月5日12:16 | #11

    犹太人的因特尔自证犹太人是多么下流无耻。希特勒太可惜了

  12. 匿名
    2018年1月6日04:57 | #12

    楼上不知道有多少傻瓜,AMD同样中招,写的清清楚楚,还下次采购只卖AMD?脑子是个好东西啊

  1. 本文目前尚无任何 trackbacks 和 pingbacks.