可怕!CPU竟成了黑客的帮凶!

2020-05-20 13:44:10 Author: bbs.pediy.com
觉得文章还不错?,点我收藏



本故事根据CPU真实漏洞改编

前情回顾

还记得我吗,我是阿Q,就是那个CPU一号车间的阿Q啊。如果你忘记了我,记得看看这里回忆一下哦:完了!CPU一味求快出事儿了!

 

自从我们车间用上了乱序执行分支预测后,生产效率那是大大提升,领导不仅在全厂的员工大会表扬了我们,还把这两项技术向全厂推广,在我们8个CPU核心车间都铺开了,性能甩开竞争对手CPU几条街。

 

可是,就在我们还沉醉在取得的成绩时,不知不觉我们竟埋下了灾难的种子······

 

 

事情还得从不久前的一个晚上说起。

神秘代码

这天晚上,我们一号车间遇到了这样一段代码:

uint8_t array1[160] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
uint8_t array2[256 * 512];
uint8_t temp = 0;

void bad_guy(int x) {
    if (x < 16) {
        temp &= array2[array1[x] * 512];
    }
}

不到一会儿功夫,我们就执行了这个bad_guy()函数很多次,这不,又来了。

 

负责取指令的小A向内存那家伙打了一通电话,让内存把参数x的内容传输过来,我们知道,以内存那蜗牛的速度,估计得让我们好等。

 

这时,负责指令译码的小胖忍不住说了:“你们看,我们这都执行这个函数好多次了,每次的参数x都是小于16的,这一次估计也差不多,要不咱们启动分支预测功能,先把小于16分支里的指令先提前做一些?大家看怎么样”

 

 

我和负责数据回写的老K互相看了一眼,都点头表示同意。

 

于是,就在等待的间隙,我们又给内存那家伙打了电话,让他把array1[x]的内容也传过来。

 

等了一会儿,数据总算传了过来:

x: 2
array1[x]: 3

拿到结果之后,我们开始一边执行x<16的比较指令,一边继续打电话给内存索要array2[3]的内容。

 

比较指令执行的结果不出所料,果然是true,接下来就要走入我们预测的分支,而我们提前已经将需要的数据准备到缓存中,省去了不少时间。

 

就这样,我们成功的预测了后续的路线,我们真是一群机智的小伙伴。

 

遭遇滑铁卢

天有不测风云,不久,事情发生了变化。

 

“呀!比较结果是false,这一次的x比16大了”,我执行完结果后发现和我们预期的有了出入。

 

小A闻讯而来,“额,咱们提前执行了不该执行的指令不会有问题吧?”

 

 

老K安慰道:“没事儿,咱们只是提前把数据读到了我们的缓存中,没问题的,放心好啦”

 

我想了想也对,大不了我们提前做的准备工作白费了,没有多想就继续去执行>16的分支指令了。

 

随后,同样的事情也时有发生,渐渐的我们就习惯了。

灾难降临

夜越来越深,我们都有点犯困了,突然,领导来了一通电话,让我们放下手里的工作火速去他办公室。

 

我们几个不敢耽误,赶紧出发。

 

来到领导的办公室,里面多了两个陌生人,其中一个还被绑着,领导眉头紧锁,气氛很是紧张。

 

 

“阿Q啊,你知不知道你们新发明的乱序执行分支预测技术闯了大祸了?”

 

我们几个一听傻眼了,“领导,这是从何说起啊?”

 

领导从椅子上站了起来,指着旁边的陌生人说到:“给你们介绍一下,这是操作系统那边过来的安全员,让他告诉你们从何说起吧!”

 

这位安全员向大家点了点头,指着被捆绑那人说道:“大家好,我们抓到这个线程在读取系统内核空间的数据,经过我们的初审,他交代了是通过你们CPU的乱序执行分支预测功能实现的这一目的。”

 

我和小A几个一听都是满脸问号,我们这两个提升工作效率的技术怎么就能泄漏系统内核数据呢?

 

真相大白

安全员显然看出了我们的疑惑,指着被捆绑的那个线程说道:“你把之前交代的再说一遍”

 

“几位大爷,你们之前是不是遇到了分支预测失败的情况?”,那人抬头看着我们。

 

“有啊,跟这有什么关系?失败了很正常嘛,既然是预测那就不能100%打包票能预测正确啊”,我回答道。

 

您说的没错,不过如果这个失败是我故意策划的呢?

 

 

听他这么一说,我的心一下悬了起来,“纳尼,你干的?”

 

“是的,就是我,我先故意给你连续多次小于16的参数,误导你们,误以为后面的参数还是小于16的,然后突然来一个特意构造的大于16的参数,你们果然上钩了,预测失败,提前执行了一些本不该执行的指令。”

 

“那又如何呢?我们只是把后面需要的数据提前准备到了缓存中,并没有进一步做什么啊”,我还是不太明白。

 

这就够了!

 

“你小子都被捆上了,就别吊胃口了,一次把话说清楚”,一旁急性子的老K忍不住了。

 

 

“好好好,我这就交代。你们把数据提前准备到了缓存中,我后面去访问这部分数据的时候,发现比访问其他内存快了很多”

 

“那可不,我们的缓存技术可不是吹牛的!哎等等,怎么又扯到缓存上去了?”,老K继续问道。

 

那人继续说道:“如果我想知道某个地址单元内的值,我就以它作为数组的偏移,去访问一片内存区域。利用你们会提前预测执行而且会把数据缓存的机制。你们虽然预测失败了,但对应的那一块数据已经在缓存中了,接着,我依次去访问那一片内存,看看谁的访问时间明显比其他部分短,那就知道哪一块被缓存了,再接着反推就能知道作为偏移的数值是多少了,按照这个思路我可以知道每一个地址单元的内容”

 

 

我们几个一边听着一边想着,琢磨了好一会儿总算弄清楚了这家伙的套路,老K气得火冒三丈,差点就想动手修理那人。

 

“好你个家伙,倒是挺聪明的,可惜都不用在正途上!好好的加速优化机制竟然成为了你们的帮凶”,我心中也有一团火气。

亡羊补牢

事情的真相总算弄清楚了,我们几个此刻已经汗流浃背。

 

经过和安全员的协商,操作系统那边推出了全新的KPTI技术来解决这个问题,也就是内核页表隔离

 

 

以前的时候,线程执行在用户态和内核态时用的是同一本地址翻译手册,也就是人们说的页表,通过这本手册,我们CPU就能通过虚拟地址找到真实的内存页面。

 

现在好了,让线程运行在用户态和内核态时使用不同的手册,用户态线程的手册中,内核地址空间部分是一片空白,来一招釜底抽薪!

 

本以为我们可以回去了,没想到领导却给我们出了难题,“这祸是你们闯下的,人家操作系统那边虽然做了保护,你们是不是也该拿出点办法来呢,要不然以后我们CPU还怎么抬得起头来?”

 

你有什么好办法吗,帮帮我们吧!

幕后

本文描述的是两年前爆发的大名鼎鼎的CPU的熔断幽灵漏洞。

乱序执行分支预测是现代处理器普遍采用的优化机制。和传统软件漏洞不同,硬件级别的漏洞影响更大更深也更难以修复。

通过判断内存的访问速度来获知是否有被缓存,这类技术有一个专门的术语叫侧信道,即通过一些场外信息来分析得出重要结论,进而达成正常途径无法达成的目的。

后面的文章中此类手法的故事还将继续上演,敬请期待!

 

特别鸣谢:网友几多风雨劲提供的技术支持

往期热门回顾

完了!CPU一味求快出事儿了!

 

哈希表哪家强?几大编程语言吵起来了!

 

内核地址空间大冒险4:线程切换

 

震撼!全网第一张源码分析全景图揭秘Nginx

 

一个整数+1引发的灾难

 

一网打尽!每个程序猿都该了解的黑客技术大汇总

 

看过无数Java GC文章,这5个问题你也未必知道!

 

一个Java对象的回忆录:垃圾回收

 

谁动了你的HTTPS流量?

 

路由器里的广告秘密

 

一个HTTP数据包的奇幻之旅

 

我是一个流氓软件线程

 

 

[培训]科锐逆向工程师培训班38期--远程教学预课班将于 2020年5月28日 正式开班!




觉得文章还不错?,点我收藏



如果文章侵犯到您的版权,请联系我:buaq.net[#]pm.me