基于指令校驗(yàn)的軟硬件協(xié)同代碼重用攻擊防護(hù)方法

呂雅帥

(中國(guó)人民解放軍裝備學(xué)院 國(guó)防科技重點(diǎn)實(shí)驗(yàn)室,北京 101416)

?

基于指令校驗(yàn)的軟硬件協(xié)同代碼重用攻擊防護(hù)方法

呂雅帥

(中國(guó)人民解放軍裝備學(xué)院 國(guó)防科技重點(diǎn)實(shí)驗(yàn)室,北京 101416)

面向x86處理器的代碼重用攻擊難于防護(hù)的一個(gè)重要原因是,在x86程序代碼中存在大量合法但非編程者預(yù)期要執(zhí)行的指令.這些在代碼中大量存在的非預(yù)期指令可被用于構(gòu)造實(shí)現(xiàn)CRA的組件.先前研究均采用軟件方法解決非預(yù)期指令問(wèn)題,運(yùn)行開(kāi)銷大且應(yīng)用受限.本文的主要貢獻(xiàn)之一是提出了一種低開(kāi)銷的軟硬件協(xié)同方法來(lái)解決x86的非預(yù)期指令問(wèn)題.實(shí)驗(yàn)表明,本文的實(shí)現(xiàn)方法僅給應(yīng)用程序帶來(lái)了-0.093%～2.993%的額外運(yùn)行開(kāi)銷.此外,本文還提出采用硬件實(shí)現(xiàn)的控制流鎖定作為一項(xiàng)補(bǔ)充技術(shù).通過(guò)同時(shí)采用兩個(gè)技術(shù),可以極大降低x86平臺(tái)遭受代碼重用攻擊的風(fēng)險(xiǎn).

代碼重用攻擊；非預(yù)期指令；指令校驗(yàn)

1 引言

長(zhǎng)期以來(lái),代碼注入攻擊是最常用的一種惡意代碼攻擊手段.為了阻止代碼注入攻擊,研究者與業(yè)界提出并實(shí)現(xiàn)了一種名為W⊕X的保護(hù)機(jī)制.W⊕X機(jī)制限制了操作系統(tǒng)一個(gè)存儲(chǔ)頁(yè)的寫(xiě)入和執(zhí)行是互斥的.W⊕X目前已被主流的處理器和操作系統(tǒng)如Windows、Linux等采用.W⊕X機(jī)制基本杜絕了進(jìn)行代碼注入攻擊的可能性.但近年又出現(xiàn)了一種新的攻擊手段可以繞過(guò)W⊕X防護(hù)機(jī)制,即代碼重用攻擊(code-reuse attack,CRA).CRA利用應(yīng)用程序自身的代碼實(shí)現(xiàn)惡意攻擊,而不用像代碼注入那樣對(duì)運(yùn)行中的程序進(jìn)行修改.CRA最早源于return-to-libc技術(shù).在return-to-libc攻擊中,攻擊者首先破壞運(yùn)行棧并將控制流轉(zhuǎn)移至一個(gè)現(xiàn)有的libc函數(shù),然后通過(guò)調(diào)用系統(tǒng)函數(shù)來(lái)加載惡意代碼并繞過(guò)W⊕X防護(hù)機(jī)制.在2007年的論文[1]中,Shacham提出了return-oriented programming (ROP)攻擊技術(shù).與return-to-libc相比,ROP攻擊不但同樣可以繞過(guò)W⊕X機(jī)制,并且被證明是圖靈完備的.ROP利用所謂的一系列組件(gadget,以函數(shù)返回指令ret為結(jié)束的短代碼序列)來(lái)構(gòu)造惡意代碼.自從ROP出現(xiàn)后,研究者提出了一系列應(yīng)對(duì)ROP攻擊的方法[2,3].然而,一種新的CRA方法—jump-oriented programming(JOP)[4,5]又被開(kāi)發(fā)出來(lái).JOP不需要以ret指令作為組件的結(jié)束指令.JOP不但大大降低了在CRA中構(gòu)造惡意代碼的困難程度,而且使得原先應(yīng)對(duì)ROP攻擊的防護(hù)技術(shù)都完全失效.

在x86平臺(tái)的二進(jìn)制代碼中尋找CRA組件要遠(yuǎn)比RISC處理器平臺(tái)容易.這是因?yàn)樵趚86二進(jìn)制代碼中存在著大量合法但不是編程者預(yù)期要執(zhí)行的指令(unintended instruction).ROP和JOP攻擊往往利用這些非預(yù)期指令構(gòu)造CRA所需的組件.目前缺乏有效應(yīng)對(duì)面向x86處理器代碼重用攻擊的一個(gè)重要原因就在于,非預(yù)期指令問(wèn)題沒(méi)有得到很好地解決.本文的貢獻(xiàn)主要有以下幾點(diǎn):(1)提出了一種軟硬件協(xié)同實(shí)現(xiàn)方法,解決了x86處理器的非預(yù)期指令問(wèn)題,該方法只需對(duì)處理器和操作系統(tǒng)進(jìn)行細(xì)微修改,且不需要對(duì)二進(jìn)制應(yīng)用程序本身進(jìn)行任何修改；(2)進(jìn)一步提出了利用硬件實(shí)現(xiàn)的控制流鎖定作為一項(xiàng)補(bǔ)充技術(shù),兩者相結(jié)合可以極大增加面向x86處理器代碼重用攻擊的難度；(3)上述技術(shù)通過(guò)用周期精確CPU模擬器進(jìn)行測(cè)試,實(shí)驗(yàn)結(jié)果表明,本文提出的方法對(duì)應(yīng)用程序運(yùn)行性能的影響非常小.

2 相關(guān)研究

自從CRA出現(xiàn)后,研究者提出了一系列防護(hù)技術(shù)來(lái)應(yīng)對(duì),但絕大部分針對(duì)ROP攻擊.文獻(xiàn)[6,7]提出用影子棧技術(shù)防止攻擊者通過(guò)破壞運(yùn)行棧來(lái)改變程序的控制流.文獻(xiàn)[2,3]通過(guò)監(jiān)測(cè)返回指令的運(yùn)行狀態(tài)來(lái)探測(cè)CRA組件,而文獻(xiàn)[8,9]則通過(guò)監(jiān)測(cè)call-ret指令對(duì)來(lái)檢測(cè)ROP攻擊.另外一些研究通過(guò)修改庫(kù)代碼[10,11],消滅那些可能被用作組件的代碼片段來(lái)降低利用系統(tǒng)庫(kù)代碼進(jìn)行CRA的可能性.這些研究中所提出的方法主要是應(yīng)對(duì)ROP攻擊,對(duì)JOP攻擊而言,這些防護(hù)技術(shù)是無(wú)效的.

相對(duì)于ROP而言,JOP是較近提出的CRA技術(shù),所以針對(duì)JOP的防護(hù)技術(shù)比較少.在已提出的JOP防護(hù)方法中,文獻(xiàn)[12,13]采用的是純軟件方式.純軟件方式必須依賴動(dòng)態(tài)二進(jìn)制翻譯,這意味著應(yīng)用程序運(yùn)行性能會(huì)受嚴(yán)重影響.Kayaalp等在文獻(xiàn)[9]中采用的是軟硬件相結(jié)合的手段.該方法僅阻止了函數(shù)間組件的跳轉(zhuǎn),但攻擊者還是有可能利用一個(gè)函數(shù)內(nèi)的組件實(shí)現(xiàn)攻擊.Kayaalp等在文獻(xiàn)[14]中又提出了一種基于已知CRA特征,通過(guò)硬件在線識(shí)別并阻止CRA的方法.該方法不需要對(duì)軟件進(jìn)行修改,但需要用戶設(shè)定檢測(cè)閾值來(lái)探測(cè)CRA攻擊.該方法的一個(gè)主要缺陷在于要依賴已知的CRA特征來(lái)檢測(cè),對(duì)于未知的攻擊特征則無(wú)法檢測(cè).

實(shí)現(xiàn)面向x86處理器CRA攻擊的一個(gè)重要手段是借助x86代碼中的非預(yù)期指令序列.在CRA被提出之前,有研究者已經(jīng)意識(shí)到非預(yù)期指令是x86處理器潛在的安全隱患,提出了在應(yīng)用程序沙箱中對(duì)非預(yù)期指令進(jìn)行檢測(cè)[15].這種軟件檢測(cè)非預(yù)期指令的方法給應(yīng)用程序帶來(lái)的性能損失較大.與前述研究相比,本文的一個(gè)重要貢獻(xiàn)是通過(guò)軟硬件協(xié)同手段解決了x86處理器的非預(yù)期指令這一潛在安全隱患,極大增加了實(shí)施CRA攻擊的難度.

3 方法與實(shí)現(xiàn)

本文提出的CRA防護(hù)方法主要解決兩個(gè)方面的問(wèn)題:(1)防止處理器執(zhí)行非預(yù)期指令；(2)防止處理器進(jìn)行非預(yù)期的控制流轉(zhuǎn)移.

3.1 校驗(yàn)非預(yù)期指令

像x86這樣CISC處理器的一個(gè)重要特點(diǎn)就是指令長(zhǎng)度是可變的,每條指令不需要像RISC處理器那樣對(duì)齊到32位或64位地址邊界上,代碼段每一個(gè)起始地址都有可能是一條新指令的開(kāi)始.這造成的一個(gè)結(jié)果就是一段二進(jìn)制代碼可被解釋成多個(gè)完全不同的有效指令序列.CRA正是利用了x86處理器的這一特點(diǎn)來(lái)構(gòu)造惡意攻擊所需的組件.圖1展示了這一現(xiàn)象.

圖1中反匯編代碼片段抽取自libc-2.12-32的-IO-vfprintf函數(shù).在正常解碼的情況下,該片段包含三條指令(圖1的上半部分所示).然而,如果從call指令的第三個(gè)字節(jié)開(kāi)始解碼,就是一個(gè)完全不同的代碼序列(圖1的下半部分所示).該序列同樣包含三條合法指令,但卻不是編程人員想要執(zhí)行的.由于最后一條指令恰好為間接跳轉(zhuǎn)指令,因此這三條非預(yù)期指令極有可能被用作CRA攻擊的組件.值得指出的是,在x86平臺(tái)上從非預(yù)期指令中尋找間接跳轉(zhuǎn)指令是非常容易的.因?yàn)樽止?jié)FF正好是間接跳轉(zhuǎn)指令的操作碼,而FF又恰好是很多指令的操作數(shù).由此可見(jiàn),要提升面向x86平臺(tái)的CRA防護(hù)能力,非預(yù)期指令是必須要解決的一個(gè)重要問(wèn)題.

3.1.1 PC校驗(yàn)表

處理器流水線中取指是比較適合進(jìn)行非預(yù)期指令檢測(cè)的地方.如何在取指時(shí)判斷PC所指向的指令是否是非預(yù)期指令呢？前面提到過(guò),所有非預(yù)期指令都是合法指令,也就是說(shuō),僅從指令編碼本身是無(wú)法作出判斷的,只有通過(guò)PC,也就是該指令的地址,才能判斷一條指令是否是非預(yù)期指令.那如何判斷一個(gè)PC是否是合法的呢？本文借助一個(gè)合法的PC校驗(yàn)列表進(jìn)行比較.

一種獲取合法PC列表的方式是在程序運(yùn)行前對(duì)程序的代碼段進(jìn)行反匯編.當(dāng)可執(zhí)行程序被加載至內(nèi)存時(shí),操作系統(tǒng)會(huì)知道每個(gè)代碼段在虛存中的起始地址.從某個(gè)代碼段的首字節(jié)開(kāi)始,依次對(duì)每條指令進(jìn)行反匯編,從而可以獲取每條指令的正確起始地址.當(dāng)操作系統(tǒng)采用Address Space Layout Randomization(ASLR)機(jī)制時(shí),由于僅是代碼段入口地址隨機(jī)化,且該入口地址對(duì)于操作系統(tǒng)是已知的,所以依然可以從代碼段入口對(duì)指令進(jìn)行反匯編.有了合法PC列表后,下一個(gè)問(wèn)題是以何種形式保存這個(gè)合法PC列表.如果直接以地址形式保存的話,那么處理器在對(duì)一個(gè)PC進(jìn)行判斷時(shí)就要在這個(gè)列表中進(jìn)行查找,這種方式顯然效率很低,其搜索時(shí)間為O(logn).另一種方式是用有效位“1”或“0”來(lái)表示某個(gè)地址是否是一條合法指令的起始地址,如圖2所示.通過(guò)用圖2中有效位的方式來(lái)表示合法指令,在對(duì)一個(gè)PC進(jìn)行判斷時(shí)僅需O(1)時(shí)間.3.1.2 分支地址校驗(yàn)

理論上,要確保只有合法指令才能被執(zhí)行,就需要對(duì)每一條將要被取指的指令地址進(jìn)行校驗(yàn).然而,如果程序的第一條指令指向的是合法地址(即程序沒(méi)有在一開(kāi)始就被破壞),那么實(shí)際上不需對(duì)所有指令地址進(jìn)行校驗(yàn),只需校驗(yàn)控制轉(zhuǎn)移指令的目標(biāo)地址即可.也就是說(shuō),正常指令的取指執(zhí)行操作不需要被校驗(yàn)過(guò)程打斷,直至遇到分支轉(zhuǎn)移指令.所以,非預(yù)期指令校驗(yàn)僅需在分支指令的分支目標(biāo)地址被處理器流水線計(jì)算出來(lái)后進(jìn)行.此外,如果系統(tǒng)采用了W⊕X機(jī)制的話,那么理論上只需校驗(yàn)間接分支指令即可.這是因?yàn)橹苯臃种е噶畹牡刂肥菍?xiě)在指令操作數(shù)中的,當(dāng)使用W⊕X機(jī)制時(shí),惡意代碼是無(wú)法修改指令操作數(shù)的.

圖3給出了簡(jiǎn)要的校驗(yàn)流程.首先,待校驗(yàn)的分支目標(biāo)地址會(huì)與已校驗(yàn)地址緩存中的地址進(jìn)行比較,如果命中則表明該地址合法.已校驗(yàn)地址緩存中存放了最近校驗(yàn)成功的分支目標(biāo)地址.當(dāng)沒(méi)有命中已校驗(yàn)地址緩存時(shí),則需要與存放在內(nèi)存中的校驗(yàn)數(shù)據(jù)進(jìn)行比較.訪問(wèn)內(nèi)存中的數(shù)據(jù)需要首先確定待校驗(yàn)地址屬于哪個(gè)代碼段,這一過(guò)程借助代碼段查找表完成.代碼段查找表中存放了校驗(yàn)數(shù)據(jù)在內(nèi)存中的對(duì)應(yīng)位置,獲取校驗(yàn)數(shù)據(jù)位置之后,便可以按圖2中的方法來(lái)獲取待校驗(yàn)地址所對(duì)應(yīng)的校驗(yàn)數(shù)據(jù).下面將分別闡述已校驗(yàn)地址緩存和代碼段查找表的設(shè)計(jì),以及如何在處理器流水線中實(shí)現(xiàn)該校驗(yàn)流程.

已校驗(yàn)地址緩存的結(jié)構(gòu)如圖4所示,其功能是緩存最近校驗(yàn)通過(guò)的分支目標(biāo)地址,從而減少因校驗(yàn)地址引起的處理器停頓.該已校驗(yàn)地址緩存的結(jié)構(gòu)與組相連cache相似,其存儲(chǔ)空間被劃分為N行和M組.待校驗(yàn)分支目標(biāo)地址通過(guò)一個(gè)hash函數(shù)決定屬于哪個(gè)組.每個(gè)組包含N個(gè)校驗(yàn)過(guò)的地址項(xiàng)或無(wú)效項(xiàng).待校驗(yàn)的地址與一個(gè)組中的所有地址進(jìn)行并行比較,以快速?zèng)Q定該地址是否命中緩存.該緩存實(shí)現(xiàn)時(shí)可采用偽LRU算法作為組內(nèi)校驗(yàn)地址項(xiàng)的替換策略.顯而易見(jiàn),已校驗(yàn)地址緩存的硬件開(kāi)銷主要依賴于其所需存儲(chǔ)空間,本文將在實(shí)驗(yàn)部分討論該問(wèn)題.

代碼段查找表里存放代碼段的起始地址和相應(yīng)校驗(yàn)數(shù)據(jù)在內(nèi)存中的存放位置.代碼段查找表中的項(xiàng)與應(yīng)用程序?qū)嶋H代碼段沒(méi)有必要一一對(duì)應(yīng).可以把連續(xù)的代碼段合并為代碼段查找表中的一項(xiàng),以減少代碼段查找表的項(xiàng)數(shù).

如圖5所示,完整的代碼段查找表存放在內(nèi)存中,并由操作系統(tǒng)進(jìn)行維護(hù).像TLB一樣,在處理器中也有相應(yīng)的代碼段查找表緩存,該緩存存放了最近使用的代碼段查找表項(xiàng).待校驗(yàn)地址首先訪問(wèn)該緩存,如果命中則從內(nèi)存相應(yīng)位置訪問(wèn)校驗(yàn)數(shù)據(jù),否則引發(fā)處理器中斷,操作系統(tǒng)從完整的代碼段查找表中尋找相應(yīng)項(xiàng),并加載至緩存.

接下來(lái)闡述如何將校驗(yàn)過(guò)程與亂序發(fā)射處理器流水線集成,圖6給出了集成方案的示意圖.前面提到過(guò),沒(méi)有必要對(duì)每一條取出的指令地址進(jìn)行校驗(yàn),而只需校驗(yàn)分支地址即可.所以可把校驗(yàn)過(guò)程從處理器流水線的取指階段轉(zhuǎn)移到提交階段.這主要基于兩點(diǎn)考慮:(1)一個(gè)分支指令的分支目標(biāo)只有在經(jīng)過(guò)執(zhí)行階段后才能確定；(2)對(duì)于亂序發(fā)射流水線來(lái)說(shuō),只有進(jìn)入了提交階段的分支指令才是真正要執(zhí)行的分支指令.然而,如果在一條分支指令正要提交時(shí)對(duì)其分支地址進(jìn)行校驗(yàn),那么即使能夠命中已校驗(yàn)地址緩存,也需要流水線停頓一到兩個(gè)時(shí)鐘周期來(lái)確定校驗(yàn)結(jié)果.一種較好的處理方法是在分支指令位于ROB隊(duì)列前面但還未提交時(shí)進(jìn)行校驗(yàn),并用一位來(lái)表示是否校驗(yàn)成功.

圖6同時(shí)也給出了在處理器流水線中的具體校驗(yàn)流程.首先,當(dāng)分支指令接近ROB頂端時(shí),在已校驗(yàn)地址緩存中檢查是否存在該分支目標(biāo)地址.如果未命中,便查詢分支預(yù)測(cè)器中的分支目標(biāo)緩存(BTB).如果BTB也沒(méi)有命中,則需要從內(nèi)存調(diào)取校驗(yàn)數(shù)據(jù).這一過(guò)程首先要通過(guò)代碼段查找表緩存查詢校驗(yàn)數(shù)據(jù)在內(nèi)存中的位置,然后通過(guò)ITLB轉(zhuǎn)換成物理地址,從而去內(nèi)存中獲取數(shù)據(jù).接下來(lái)的流程有兩種選擇方案,一種是單獨(dú)設(shè)置一個(gè)指令校驗(yàn)cache(即圖中的IV-Cache)存放校驗(yàn)數(shù)據(jù)；另一種方案是利用指令cache存放校驗(yàn)數(shù)據(jù).利用指令cache顯然會(huì)擠占指令的緩存空間,但實(shí)驗(yàn)部分的測(cè)試數(shù)據(jù)表明,利用指令cache的方案并不會(huì)對(duì)應(yīng)用程序性能造成太大影響.

3.2 控制流校驗(yàn)

本小節(jié)介紹如何通過(guò)進(jìn)一步措施來(lái)防護(hù)CRA.前面介紹過(guò),目前CRA主要有ROP攻擊和JOP攻擊兩類.采用低開(kāi)銷硬件機(jī)制如安全調(diào)用棧等技術(shù),可以有效地阻止ROP攻擊.因此,這里主要討論如何阻止JOP攻擊.

當(dāng)系統(tǒng)使用W⊕X機(jī)制時(shí),攻擊者無(wú)法利用直接控制轉(zhuǎn)移指令進(jìn)行惡意攻擊,因?yàn)樘D(zhuǎn)地址直接寫(xiě)在操作數(shù)中,攻擊者無(wú)法進(jìn)行修改.實(shí)際上,JOP攻擊可利用的也只能是間接跳轉(zhuǎn)指令.值得指出的是,一個(gè)應(yīng)用程序在實(shí)現(xiàn)時(shí),如果嚴(yán)格遵循結(jié)構(gòu)化編程的原則,而不刻意使用goto語(yǔ)句或以嵌入?yún)R編方式使用間接跳轉(zhuǎn)指令,那么程序控制流轉(zhuǎn)移的地址實(shí)際上在高級(jí)語(yǔ)言編譯時(shí)均是可知的.因此,可以采用Bletsch等人在文獻(xiàn)[16]中提出的一種叫控制流鎖定(Control-Flow Locking)的技術(shù)來(lái)校驗(yàn)程序控制流是否在進(jìn)行正常轉(zhuǎn)移.

控制流鎖定的思想類似于多線程同步機(jī)制中互斥變量加解鎖的概念.Bletsch等人所提出的控制流鎖定技術(shù)采用軟件手段實(shí)現(xiàn),每條間接跳轉(zhuǎn)指令之前都會(huì)加入一個(gè)“加鎖”代碼片段,在跳轉(zhuǎn)的目的地址處加入一個(gè)“解鎖”代碼片段.顯然,如果程序運(yùn)行過(guò)程中每次間接跳轉(zhuǎn)均需要運(yùn)行“加解鎖”代碼的話,其開(kāi)銷是非常大的.本文在這里提出一種硬件實(shí)現(xiàn)的方式,不需要加入“加解鎖”代碼片段.而是在每個(gè)跳轉(zhuǎn)目標(biāo)指令前加一個(gè)前綴以標(biāo)明該指令為特殊的“解鎖”指令.對(duì)于每條成功提交的間接跳轉(zhuǎn)指令,處理器自動(dòng)進(jìn)入一個(gè)“跳轉(zhuǎn)加鎖”的狀態(tài).若提交的下一條指令是“解鎖”指令,則處理器解除“跳轉(zhuǎn)鎖定”狀態(tài),否則觸發(fā)處理器異常.

圖7給出了一個(gè)示例.地址0x451處間接跳轉(zhuǎn)指令的目的地址是0x4f0.處理器完成jmp rax指令的提交后會(huì)進(jìn)入“跳轉(zhuǎn)鎖定”狀態(tài).地址0x4f0處原本應(yīng)該是一條ret指令,但由于它是一個(gè)跳轉(zhuǎn)的目標(biāo)地址,所以在編譯器編譯源代碼時(shí),會(huì)將該指令修改為一條帶“解鎖”前綴的ret指令(即unlock ret).帶有“解鎖”前綴的指令除完成該指令自身的功能外,還可解除處理器的“跳轉(zhuǎn)鎖定”狀態(tài).如果處理器沒(méi)有處于“跳轉(zhuǎn)鎖定”時(shí)執(zhí)行了有“解鎖”前綴的指令,則會(huì)忽略“解鎖”前綴,僅執(zhí)行該指令的正常功能.硬件上實(shí)現(xiàn)上述控制流鎖定機(jī)制十分簡(jiǎn)單,一是增加一個(gè)處理器狀態(tài)來(lái)標(biāo)識(shí)“跳轉(zhuǎn)鎖定”狀態(tài),二是在指令譯碼部分增加對(duì)“解鎖”前綴的譯碼.而在軟件上,則需編譯器在對(duì)高級(jí)語(yǔ)言進(jìn)行編譯時(shí),將所有跳轉(zhuǎn)目標(biāo)處的指令修改為帶有“解鎖”前綴的指令,從而實(shí)現(xiàn)程序運(yùn)行時(shí)處理器“跳轉(zhuǎn)鎖定”狀態(tài)的正確解鎖.

通過(guò)實(shí)現(xiàn)非預(yù)期指令和控制流的雙重校驗(yàn),可以極大降低x86平臺(tái)代碼重用攻擊的概率.

4 實(shí)驗(yàn)評(píng)估

對(duì)于本文所提出的方法,我們?cè)趃em5模擬器上實(shí)現(xiàn)并進(jìn)行性能模擬.本文實(shí)驗(yàn)在一臺(tái)高性能臺(tái)式機(jī)上完成,處理器為3.4GHz Core i7-4770,內(nèi)存16GB,操作系統(tǒng)為CentOS 6.4 x86-64.本文從SPECCPU 2006測(cè)試集中選取了21個(gè)程序進(jìn)行測(cè)試評(píng)估.對(duì)于每一個(gè)應(yīng)用,測(cè)試運(yùn)行100億條指令或直至其運(yùn)行完畢.

首先,對(duì)已校驗(yàn)地址緩存的大小進(jìn)行評(píng)估.設(shè)計(jì)已校驗(yàn)地址緩存的目的是提供快速校驗(yàn)地址查詢以減少處理器停頓.為了能夠進(jìn)行低延遲并行比較,組內(nèi)的項(xiàng)數(shù)不能設(shè)置太多.在本文工作中,每組設(shè)置4項(xiàng),并用偽LRU算法作為替換策略.而對(duì)于hash函數(shù),本文工作使用地址的低位作為組索引,既易于實(shí)現(xiàn)同時(shí)也有很高的命中率.有了這些假定后,現(xiàn)在所要關(guān)注的是需要設(shè)置多少組才能提供足夠高的命中率.

圖8給出了校驗(yàn)所有控制轉(zhuǎn)移指令時(shí),組數(shù)目與緩存命中率間關(guān)系,圖9則給出了僅校驗(yàn)間接跳轉(zhuǎn)指令時(shí),組數(shù)目與緩存命中率間關(guān)系.從兩個(gè)圖的數(shù)據(jù)可以看出,這些應(yīng)用程序可以大致分為兩類:計(jì)算密集型和控制密集型.計(jì)算密集型應(yīng)用在組數(shù)目非常小時(shí)依然可以獲得較高的命中率.如果把標(biāo)準(zhǔn)設(shè)定為64組命中率在90%以上,那么對(duì)于圖8來(lái)說(shuō),計(jì)算密集型應(yīng)用包括bzip2、mcf、milc、zeusmp、cactusADM、leslie3d、namd、soplex、calculix、hmmer、GemsFDTD、libquantum、h264ref和lbm.由于圖9中的實(shí)驗(yàn)僅校驗(yàn)間接跳轉(zhuǎn)指令,所以地址沖突要小于圖8,并可以看到,對(duì)于同樣的組數(shù)和應(yīng)用,圖9的命中率要高于圖8.此外,從兩個(gè)圖的數(shù)據(jù)可以得出的一個(gè)重要結(jié)論是,當(dāng)組數(shù)高于128時(shí),命中率變化趨于平穩(wěn).在圖8中,平均命中率在組數(shù)為128、256和512時(shí),分別是94.68%、97.35%和98.84%；在圖9中,平均命中率在組數(shù)為128、256和512時(shí),分別是99.11%、99.61%和99.70%.基于這樣的觀察,本文選擇128作為下面實(shí)驗(yàn)中已校驗(yàn)地址緩存的組數(shù),那么緩存的總項(xiàng)數(shù)為128×4=512.

接下來(lái)使用三種不同的配置進(jìn)行進(jìn)一步的性能評(píng)估.第一種配置是校驗(yàn)所有控制轉(zhuǎn)移指令并使用系統(tǒng)自帶分支預(yù)測(cè)器作為后備已校驗(yàn)地址緩存(記作BP&AC)；第二種配置是僅校驗(yàn)間接跳轉(zhuǎn)指令并使用系統(tǒng)自帶分支預(yù)測(cè)器作為后備已校驗(yàn)地址緩存(記作BP&IC)；第三種是僅校驗(yàn)間接跳轉(zhuǎn)指令但不使用系統(tǒng)自帶分支預(yù)測(cè)器作為后備已校驗(yàn)地址緩存(記作IC).圖10展示了基準(zhǔn)配置與上述三種配置下的指令吞吐率(IPC)對(duì)比.這里將x86指令分解后的微操作記為一條指令.為了能更清楚地進(jìn)行對(duì)比,圖11～圖13展示了上述三種配置相對(duì)基準(zhǔn)配置的性能損失.

從圖10可以看到,無(wú)論對(duì)于哪一種配置,本文所提出校驗(yàn)機(jī)制對(duì)于應(yīng)用程序的性能影響均是比較小的.對(duì)于BP&AC配置來(lái)說(shuō),平均性能損失為2.492%,其中性能損失最高為12.623%(omnetpp),最低為-0.039%(bzip2,負(fù)值意味著有一定性能提升),且有11個(gè)應(yīng)用性能損失低于1%.正如可以預(yù)見(jiàn)的那樣,BP&IC配置性能損失最低,在-0.093%至2.993%之間,平均為0.284%.其中僅有兩個(gè)應(yīng)用性能損失超過(guò)1%,18個(gè)應(yīng)用性能損失低于0.3%.在沒(méi)有自帶分支預(yù)測(cè)器的支持下,IC配置性能損失略高,但優(yōu)于BP&AC配置,其性能損失在0.043%至5.247%之間,平均為0.616%.

如果將圖10～圖13的性能測(cè)試數(shù)據(jù)與圖8和圖9的已校驗(yàn)地址緩存命中率數(shù)據(jù)進(jìn)行對(duì)比可以發(fā)現(xiàn),命中率通常與性能損失成反比.舉例來(lái)說(shuō),omnetpp在所有應(yīng)用中命中率是最低的,其性能損失在所有三種配置中也是最高的.觀察性能數(shù)據(jù)可以發(fā)現(xiàn)一個(gè)有意思的現(xiàn)象是,有些應(yīng)用實(shí)際上性能還有略微提升.經(jīng)過(guò)進(jìn)一步分析發(fā)現(xiàn),首先,這些應(yīng)用的已校驗(yàn)地址緩存命中率都比較高；其次,2級(jí)cache命中率比基準(zhǔn)配置均有提升.這意味著處理器在從內(nèi)存中取校驗(yàn)數(shù)據(jù)時(shí),對(duì)2級(jí)cache行為造成了影響,從而使得這些應(yīng)用有一定的性能提升.由于W⊕X保護(hù)機(jī)制已廣泛應(yīng)用于當(dāng)前的計(jì)算機(jī)系統(tǒng),所以僅校驗(yàn)間接跳轉(zhuǎn)指令是足夠安全的.圖12的測(cè)試數(shù)據(jù)表明,僅校驗(yàn)間接跳轉(zhuǎn)指令對(duì)應(yīng)用程序的性能影響是非常小的.即使校驗(yàn)所有控制指令,與BP&IC配置相比,IC配置也僅帶來(lái)0.332%的平均性能損失.總體而言,BP&IC配置的性能損失在-0.093% ～2.993%之間.

表1 建立校驗(yàn)數(shù)據(jù)所需開(kāi)銷

需要指出的是,除了應(yīng)用程序正常運(yùn)行時(shí)校驗(yàn)過(guò)程所帶來(lái)的開(kāi)銷外,還有在程序運(yùn)行前對(duì)程序反匯編建立校驗(yàn)數(shù)據(jù)所帶來(lái)的開(kāi)銷.表1給出了應(yīng)用程序反匯編并建立校驗(yàn)數(shù)據(jù)所需開(kāi)銷.實(shí)驗(yàn)數(shù)據(jù)在前述3.4GHz Core i7-4770平臺(tái)上獲取的.在所有28個(gè)應(yīng)用中,僅有6個(gè)應(yīng)用耗時(shí)超過(guò)了0.1秒.由于構(gòu)建校驗(yàn)數(shù)據(jù)只在程序運(yùn)行前進(jìn)行,所以可以認(rèn)作是程序的啟動(dòng)開(kāi)銷,并不影響程序運(yùn)行時(shí)的性能.

5 結(jié)束語(yǔ)

本文主要提出了一套解決x86平臺(tái)代碼重用攻擊的硬件實(shí)現(xiàn)方法.該方法主要由兩個(gè)校驗(yàn)機(jī)制組成:一是對(duì)非預(yù)期指令的校驗(yàn),二是對(duì)程序控制流的校驗(yàn).相對(duì)于先前的研究工作,本文的貢獻(xiàn)主要在對(duì)非預(yù)期指令的校驗(yàn)上.本文通過(guò)實(shí)驗(yàn)數(shù)據(jù)對(duì)所提出的方法進(jìn)行了評(píng)估,實(shí)驗(yàn)結(jié)果表明,對(duì)于BP&IC配置實(shí)現(xiàn)來(lái)說(shuō),應(yīng)用程序的性能損失在-0.093%～2.993%,性能影響很小.

[1]Shacham H.The geometry of innocent flesh on the bone:return-into-libc without function calls (on the x86)[A].ACM Conference on Computer and Communications Security[C].New York:ACM Press,2007.552-561.

[2]Davi L.Dynamic integrity measurement and attestation:towards defense against return-oriented programming attacks[A].ACM Workshop on Scalable Trusted Computing[C].New York:ACM Press,2009.49-54.

[3]Chen P.Drop:Detecting return-oriented programming malicious code[A].5th International Conference on Information Systems Security[C].Berlin,Heidelberg:Springer-Verlag,2009.163-177.

[4]Bletsch T.Jump-oriented programming:a new class of code-reuse attack[A].ACM Symposium on InformAtion,Computer and Communications Security[C].New York:ACM Press,2011.30-40.

[5]Checkoway S.Return-oriented programming without returns[A].ACM Conference on Computer and Communications Security[C].New York:ACM Press,2010.559-572.

[6]Davi L.ROPdefender:A Detection Tool to Defend Against Return-Oriented Programming Attacks[A].ACM Symposium on InformAtion,Computer and Communications Security[C].New York:ACM Press,2011.40-51.

[7]Francillon A.Defending embedded systems against control flow attacks[A].Proceedings of the first ACM workshop on Secure execution of untrusted code[C].New York:ACM Press,2011.19-26.

[8]Chen P.Efficient Detection of the Return-Oriented Programming Malicious Code[A].Information Systems Security:6th International Conference,ICISS 2010[C].Berlin,Heidelberg:Springer-Verlag,2010.140-155.

[9]Kayaalp M.Branch regulation:Low-overhead protection from code reuse attacks[A].39th Annual International Symposium on Computer Architecture[C].New York:ACM Press,2012.94-105.

[10] Hiser J.ILR:Where′d My Gadgets Go?[A].2012 IEEE Symposium on Security and Privacy[C].San Francisco,CA:IEEE,2012.571-585.

[11]Pappas V.Smashing the Gadgets:Hindering Return-Oriented Programming Using In-place Code Randomization[A].2012 IEEE Symposium on Security and Privacy[C].San Francisco,CA:IEEE,2012.601-615.

[12]Huang Z.A dynamic detection method against ROP and JOP[A].2012 International Conference on Systems and Informatics (ICSAI)[C].Yantai,China:IEEE,2012.1072-1077.

[13]Jacobson E.Detecting code reuse attacks with a model of conformant program execution[A].In Proceedings of the 6th International Symposium on Engineering Secure Software and Systems (ESSoS)[C].Berlin,Heidelberg:Springer-Verlag,2014.1-18.

[14]Kayaalp M.SCRAP:Architecture for signature-based protection from code reuse attacks[A].19th International Symposium on High Performance Computer Architecture (HPCA2013)[C].Shenzhen,China:IEEE,2013.258-269.

[15]Yee B.Native Client:A sandbox for portable,untrusted x86 native code[A].Proceedings of the 2009 30th IEEE Symposium on Security and Privacy[C].New York:ACM Press,2009.79-93.

[16]Bletsch T.Mitigating code-reuse attacks with control-flow locking[A].27th Annual Computer Security Applications Conference (ACSAC)[C].New York:ACM Press,2011.353-362.

呂雅帥 男,1981年生于河北邯鄲.2009年在國(guó)防科學(xué)技術(shù)大學(xué)取得計(jì)算機(jī)科學(xué)與技術(shù)博士學(xué)位.目前為中國(guó)人民解放軍裝備學(xué)院國(guó)防科技重點(diǎn)實(shí)驗(yàn)室助理研究員.研究方向?yàn)樘幚砥黧w系結(jié)構(gòu).

E-mail:freelancer-lys@163.com

An Instruction Verification Based Hardware/Software Co-design Approach for Mitigating Code-Reuse Attacks

Lü Ya-shuai

(KeyLaboratory,AcademyofEquipment,Beijing101416,China)

Code-reuse attacks (CRAs) are difficult to detect and defend,especially on widely used x86 processors.One reason is that lots of unintended but legal instructions exist in x86 binary codes.The unintended instructions make the finding of so called gadgets for CRAs is much easier than that of RISC processors.Previous studies rely on software-only means to tackle the unintended instruction problem,which makes their approaches are either very costly or can only be applied under restricted conditions.In this paper,we propose a hardware/software co-design approach to tackle the unintended instruction problem.The proposed mechanism has little performance impact on the examined SPEC CPU 2006 benchmarks.We also propose using hardware control-flow locking as a complementary technique.By using the two techniques together,an attacker will have little chance to carry out CRAs on x86 processors.

code-reuse attack; unintended instruction; instruction verification

2015-01-28;

2016-05-22；責(zé)任編輯:藍(lán)紅杰

國(guó)家自然科學(xué)基金(No.61202129)

TP303

A

0372-2112 (2016)10-2403-07

??學(xué)報(bào)URL:http://www.ejournal.org.cn

10.3969/j.issn.0372-2112.2016.10.018