Meltdown和Spectre分析以及CPU芯片漏洞攻擊實(shí)戰(zhàn)，教你如何破解macOS上的KASLR。

作者：蒸米，白小龍 @ 阿里移動(dòng)安全 來(lái)源：

https://paper.seebug.org/497/

0x00 影響

早上突然就被Meltdown和Spectre這兩個(gè)芯片漏洞刷屏了，但基本上都是一些新聞報(bào)道，對(duì)漏洞的分析和利用的信息基本為0。作為安全研究者，不能只浮在表面，還是要深入了解一下漏洞才行，于是開(kāi)始研究這方面的資料。結(jié)果發(fā)現(xiàn)其實(shí)這個(gè)硬件漏洞的影響非常廣，不光是Intel， ARM和AMD也受影響，只是AMD的影響比較小罷了。因此基本上所有的操作系統(tǒng)（Windows，macOS，Linux，Android等）都有被攻擊的風(fēng)險(xiǎn)。漏洞有兩種攻擊模式：一種被稱為Meltdown，是在用戶態(tài)攻擊內(nèi)核態(tài)，造成內(nèi)核信息泄露。另一種被稱為Spectre，一個(gè)應(yīng)用可以突破自己的沙盒限制，獲取其他應(yīng)用的信息。另外，因?yàn)槭怯布┒?，這個(gè)攻擊對(duì)云的影響非常大，利用這個(gè)漏洞，一個(gè)guest可以獲取host或同一臺(tái)服務(wù)器上其他guest的信息，可以說(shuō)是一個(gè)非常嚴(yán)重的漏洞，因此亞馬遜和google都在緊急加班修復(fù)漏洞。比如google就公布了漏洞修復(fù)的進(jìn)度在：https://support.google.com/faqs/answer/7622138。雖然是硬件漏洞，但是在系統(tǒng)或軟件層面上通過(guò)犧牲性能的方法還是可以進(jìn)行修補(bǔ)的。

0x01 原因

那么我們現(xiàn)在知道漏洞很嚴(yán)重了，那么漏洞形成的原因是什么呢？關(guān)鍵點(diǎn)在于Speculative execution（推測(cè)執(zhí)行）。推測(cè)性執(zhí)行是一種優(yōu)化技術(shù)，CPU會(huì)執(zhí)行一些可能在將來(lái)會(huì)執(zhí)行任務(wù)。當(dāng)分支指令發(fā)出之后，傳統(tǒng)處理器在未收到正確的反饋信息之前，是不會(huì)做任何工作的，而具有預(yù)測(cè)執(zhí)行能力的新型處理器，可以估計(jì)即將執(zhí)行的指令，采用預(yù)先計(jì)算的方法來(lái)加快整個(gè)處理過(guò)程。如果任務(wù)最終沒(méi)有被執(zhí)行，CPU還可以回滾到之前的狀態(tài)，就當(dāng)做什么都沒(méi)發(fā)生過(guò)一樣。但是這樣真的安全嗎？答案是，并不安全。攻擊者通過(guò)尋找或構(gòu)建一些指令就可以在CPU回滾的時(shí)間窗口里進(jìn)行一系列的攻擊。比如Google Blog中提到的邊界檢查繞過(guò)(CVE-2017-5753)，分支目標(biāo)注入(CVE-2017-5715), 惡意數(shù)據(jù)緩存加載(CVE-2017-5754)。

舉個(gè)例子，如果CPU執(zhí)行下面這段代碼：

arr1->length沒(méi)有被緩存的時(shí)候, CPU會(huì)從arr1->data[untrusted_offset_from_caller]處讀取數(shù)據(jù)，如果untrusted_offset_from_caller的值超過(guò)arr1->length，就會(huì)造成越界讀。當(dāng)然，正常情況下這并不會(huì)出現(xiàn)什么問(wèn)題，因?yàn)樵趫?zhí)行到判斷語(yǔ)句那一行的時(shí)候，CPU發(fā)現(xiàn)不對(duì)，后面的語(yǔ)句不應(yīng)該被執(zhí)行，于是會(huì)將狀態(tài)回滾到越界讀之前。

但是接下來(lái)，問(wèn)題就出現(xiàn)了。假設(shè)arr1->length，arr2->data[0x200]和arr2->data[0x300]都沒(méi)有被緩存，CPU會(huì)繼續(xù)推測(cè)執(zhí)行下面的代碼，在這里index2會(huì)根據(jù)value&1產(chǎn)生兩個(gè)不同的值0x200,0x300，而Value就是越界讀到的值。接下來(lái)，代碼會(huì)根據(jù)Value的值去讀取arr2->data[0x200]或arr2->data[0x300]的值并且這個(gè)值會(huì)被加入到緩存里。接下來(lái)，我們可以再次嘗試去讀取arr2->data[0x200]和arr2->data[0x300]，讀取時(shí)間短的那個(gè)值說(shuō)明被緩存過(guò)了，因此就可以判斷出value&1的值為0還是1，從而做到內(nèi)核信息泄露。

其實(shí)，在google的blog發(fā)布之前，就已經(jīng)存在類似的攻擊了，只是危害沒(méi)有這么大而已，今天我們就直接實(shí)戰(zhàn)一個(gè)利用Intel CPU芯片漏洞來(lái)破解macOS KASLR的攻擊。

0x02 芯片漏洞實(shí)戰(zhàn)之破解KASLR

這種攻擊比較簡(jiǎn)單，但是是后面高級(jí)攻擊的基礎(chǔ)，因此我們先從這個(gè)攻擊講起。之前我們講到，為了讓CPU效率更高，它們依靠推測(cè)性執(zhí)行在任務(wù)到來(lái)之前就提前執(zhí)行任務(wù)。同樣，數(shù)據(jù)預(yù)取就利用這個(gè)思想推測(cè)性地先將數(shù)據(jù)加載到緩存中。Intel的CPU有五個(gè)軟件預(yù)取指令：prefetcht0，prefetcht1，prefetcht2，prefetchnta和prefetchw。這些指令作用是提示CPU，告訴他一個(gè)特定的內(nèi)存位置可能很快被訪問(wèn)。然而，Intel的手冊(cè)中卻提到，預(yù)取“未映射到物理頁(yè)面的地址”會(huì)導(dǎo)致不確定的性能損失。因此，我們可以通過(guò)CPU預(yù)讀指令執(zhí)行的時(shí)間長(zhǎng)短來(lái)判斷這個(gè)地址有沒(méi)有被映射到物理頁(yè)面上。

我們知道KASLR的原理是在內(nèi)核的基址上增加一個(gè)slide，讓攻擊者無(wú)法猜測(cè)內(nèi)核在內(nèi)存中的位置。但是內(nèi)核肯定是被映射到物理頁(yè)面上的，因此我們可以使用預(yù)取指令去遍歷內(nèi)核可能的起始地址，如果執(zhí)行預(yù)取指令的時(shí)間突然變短，就說(shuō)明我們猜中了內(nèi)核的起始地址。我們?cè)诰W(wǎng)上成功找到了破解macOS 10.13 KASLR的POC，并做了一點(diǎn)簡(jiǎn)單的修改：https://pastebin.com/GSfJY72J

其中關(guān)鍵代碼如下：

這是一段匯編，參數(shù)會(huì)傳入想要預(yù)取的地址，然后利用rdtscp和rdtscp來(lái)統(tǒng)計(jì)指令執(zhí)行的時(shí)間，并返回。于是我們從內(nèi)核可能的起始地址開(kāi)始，不斷地執(zhí)行這段匯編代碼，直到我們找到內(nèi)核的起始地址為止。

可以看到在0x15c00000這一行，指令執(zhí)行的時(shí)間明顯縮短了。因此，我們可以猜出Kernel Side為0x15c00000。

0x03 修復(fù)

根據(jù)某內(nèi)部漏洞修復(fù)人員在twitter上的回復(fù)，蘋果已經(jīng)在macOS 10.13.2上對(duì)此類芯片漏洞進(jìn)行了修復(fù)，采用了犧牲性能的針對(duì)用戶態(tài)使用兩次映射的方式來(lái)解決該問(wèn)題。并號(hào)稱10.13.3上有更好的解決方案。另外iOS的A*系列芯片暫時(shí)還不受這類漏洞的影響。

0x04 總結(jié)

本篇文章只是給芯片的一系列漏洞開(kāi)了個(gè)頭，我們隨后還會(huì)有更多關(guān)于芯片漏洞的分析和利用實(shí)戰(zhàn)，歡迎繼續(xù)關(guān)注本系列的文章，謝謝。

參考文獻(xiàn)：

1. https://googleprojectzero.blogspot.hk/2018/01/reading-privileged-memory-with-side.html

2. https://siguza.github.io/IOHIDeous/

3. Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR, CCS 2016.

責(zé)任編輯：PSY

原文標(biāo)題：性能VS安全？CPU芯片漏洞攻擊實(shí)戰(zhàn)(1) - 破解macOS KASLR篇

文章出處：【微信公眾號(hào)：Linuxer】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。