芯片漏洞實戰(zhàn)之破解KASLR

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

作者：蒸米，白小龍 @ 阿里移動安全 來源：

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

0x00 影響

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

0x01 原因

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

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

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

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

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

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

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

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

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

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

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

0x03 修復(fù)

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

0x04 總結(jié)

本篇文章只是給芯片的一系列漏洞開了個頭，我們隨后還會有更多關(guān)于芯片漏洞的分析和利用實戰(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芯片漏洞攻擊實戰(zhàn)(1) - 破解macOS KASLR篇

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