建站
咨詢
售后
建站咨詢
新聞中心
一、漏洞簡(jiǎn)介
宣城ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書未來市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！
Hacking team今年爆出了針對(duì)android4.0.x-4.3.x android瀏覽器的漏洞攻擊利用代碼。該漏洞攻擊代碼，通過連續(xù)利用多個(gè)瀏覽器與內(nèi)核漏洞，完成通過javascript向虛擬內(nèi)存寫數(shù)據(jù)，執(zhí)行代碼，提升至root權(quán)限，并最終達(dá)到向目標(biāo)手機(jī)中植入惡意程序的目的。
該利用過程分為5個(gè)復(fù)雜的Stage，本文首先分析了第1個(gè)Stage，即Stage0。 攻擊代碼的Stage0階段通過一個(gè)0Day地址泄露漏洞，為后續(xù)數(shù)據(jù)填充操作完成定位地址定位的任務(wù)。此漏洞位于android-src\external\libxslt模塊中。
二、漏洞詳細(xì)信息
概述
Stage0利用的0Day漏洞原理如下：
該漏洞屬于未經(jīng)正確性檢查，就直接錯(cuò)誤地進(jìn)行強(qiáng)制類型轉(zhuǎn)換，從而導(dǎo)致一個(gè)用于內(nèi)存讀(實(shí)際用于字符串比較)的指針可以被操控。漏洞利用的思路是：通過在JS分配的大片內(nèi)存空間中，填充字符串：http://www/w3.org/1999/XSL/Transform，程序的后續(xù)邏輯會(huì)將該字符串會(huì)與那個(gè)可控內(nèi)存指針?biāo)赶虻淖址M(jìn)行比較，一旦字符串對(duì)比不成功，則javascript的一個(gè)對(duì)象會(huì)記錄下“Error”,由于指針?biāo)赶虻牡刂肥强煽刂频模坏┌l(fā)現(xiàn) “Error”，就重新調(diào)整地址，直到?jīng)]有發(fā)生Error，這樣就得到了javascript開辟的可控空間的內(nèi)存地址信息。
1. 數(shù)據(jù)結(jié)構(gòu)背景
圖1展示了hacking team所使用的觸發(fā)漏洞代碼：
圖1 漏洞觸發(fā)代碼與其內(nèi)存結(jié)構(gòu)
在瀏覽器中，我們可以使用javascript引用如圖1所示的xsl文件，通過此文件，即可引發(fā)stage0所使用的漏洞。圖1中的xsl語句，在libxml2解析后，會(huì)形成如圖1中右圖所示結(jié)構(gòu)。其中，xsl描述的cdent節(jié)點(diǎn)，即為觸發(fā)漏洞的ENTITY類型節(jié)點(diǎn)。
此漏洞發(fā)生在瀏覽器引擎對(duì)xsl文件的解析過程中。因此，我們先簡(jiǎn)述一下圖1中代碼，與右圖節(jié)點(diǎn)的對(duì)應(yīng)關(guān)系。右圖的myDoc節(jié)點(diǎn)為虛的根節(jié)點(diǎn)，在左圖xsl描述中并沒有對(duì)應(yīng)。xsl描述的最外層adoc和ata節(jié)點(diǎn)，同為根節(jié)點(diǎn)的下的一級(jí)子節(jié)點(diǎn)，由于adoc是第一個(gè)子節(jié)點(diǎn)，被myDoc的數(shù)據(jù)結(jié)構(gòu)中得children指針指向，ata則被adoc的next指針指向。同理，x節(jié)點(diǎn)，cdent節(jié)點(diǎn)和y節(jié)點(diǎn)，同為adoc的子節(jié)點(diǎn)一級(jí)，形成如上圖所示結(jié)構(gòu)。#p#
2. 漏洞成因
程序出現(xiàn)異常的根本原因是由于libxslt在對(duì)圖1中的cdent(xmlEntity類型)節(jié)點(diǎn)進(jìn)行操作時(shí)，并未對(duì)此節(jié)點(diǎn)的類型進(jìn)行比較，導(dǎo)致對(duì)cdent節(jié)點(diǎn)進(jìn)行了不正確的類型轉(zhuǎn)換(轉(zhuǎn)換為xmlNode類型)，并對(duì)轉(zhuǎn)換后的節(jié)點(diǎn)進(jìn)行了非法操作。libxslt(android瀏覽器在對(duì)xsl進(jìn)行解析時(shí)所使用的模塊)在對(duì)xsl操作的過程中，會(huì)對(duì)大部分節(jié)點(diǎn)的namespace進(jìn)行比較，判斷節(jié)點(diǎn)是否為一個(gè)合法的xsl節(jié)點(diǎn)。
但當(dāng)節(jié)點(diǎn)類型為xmlEntity類型時(shí)，由于xmlEntity沒有ns(用來比較namespace信息的數(shù)據(jù)結(jié)構(gòu))字段，所以不對(duì)xmlEntity類型進(jìn)行比較namespace操作(xmlEntity類型、xmlNode類型的詳細(xì)信息請(qǐng)看圖5)。而libxslt在判斷節(jié)點(diǎn)類型是否為xmlEntity時(shí)，libxslt的判斷并不完全，最終導(dǎo)致xmlEntity可被轉(zhuǎn)換為xmlNode進(jìn)行操作。從而引發(fā)程序崩潰。
圖2 未對(duì)所有節(jié)點(diǎn)的類型進(jìn)行判斷
觸發(fā)崩潰的第一步，是由于對(duì)節(jié)點(diǎn)類型的比較不完全導(dǎo)致的。libxslt在成功構(gòu)建節(jié)點(diǎn)樹(如圖2中右圖)后，會(huì)循環(huán)對(duì)myDoc的子節(jié)點(diǎn)進(jìn)行namespace比較操作，圖2中左側(cè)代碼，是在循環(huán)中當(dāng)對(duì)當(dāng)前節(jié)點(diǎn)的所有操作完成時(shí)，將循環(huán)操作中的節(jié)點(diǎn)指針指向下一個(gè)需要操作的節(jié)點(diǎn)的代碼。根據(jù)圖2中第4967行的代碼，我們可以發(fā)現(xiàn)，libxslt是希望當(dāng)目標(biāo)節(jié)點(diǎn)子節(jié)點(diǎn)或next節(jié)點(diǎn)的類型不為xmlEntity類型時(shí)，將目標(biāo)節(jié)點(diǎn)子節(jié)點(diǎn)或next節(jié)點(diǎn)賦值給cur指針，再由cur指針進(jìn)入下一次循環(huán)。但是，libxslt只對(duì)cur指針的第一個(gè)子節(jié)點(diǎn)進(jìn)行了數(shù)據(jù)類型的比較操作，并沒有對(duì)cur指針的next節(jié)點(diǎn)進(jìn)行數(shù)據(jù)類型的比較。而在我們構(gòu)建的節(jié)點(diǎn)結(jié)構(gòu)中，cdent(xmlEntity類型)節(jié)點(diǎn)，正是被x的next指針指向的，導(dǎo)致cdent節(jié)點(diǎn)不正確的進(jìn)入了循環(huán)。
圖3 對(duì)namespace進(jìn)行比較的函數(shù)
觸發(fā)崩潰的第二步，是xmlEntity節(jié)點(diǎn)被轉(zhuǎn)換為xmlNode節(jié)點(diǎn)。圖3為第一步中所說的循環(huán)的開始位置(圖3代碼的4893行)，我們可以清晰的看到第一步所用的cur指針的數(shù)據(jù)類型為xmlNode類型。而第一步的xmlEntity類型被賦值給了xmlNode類型的指針，這就導(dǎo)致了類型轉(zhuǎn)換的錯(cuò)誤。
圖4 IS_XSLT_ELEM宏的定義
觸發(fā)崩潰的第三步，是對(duì)不正確的數(shù)據(jù)類型進(jìn)行了非法操作。圖4為圖3中IS_XSLT_ELEM宏的展開。IS_XSLT_ELEM宏的操作是比較節(jié)點(diǎn)的namespace，判斷xmlNode結(jié)構(gòu)體中的ns字段(此字段指向一個(gè)xmlNs的數(shù)據(jù)類型)中的href字段所指向的地址是否存儲(chǔ)了字符串“http://www.w3.org/1999/XSL/Transform”。
圖5 相互轉(zhuǎn)換的兩種數(shù)據(jù)類型
當(dāng)IS_XSLT_ELEM宏的輸入?yún)?shù)為一個(gè)xmlEntity類型時(shí)，宏就會(huì)將orig字符串當(dāng)作xmlNs類型的數(shù)據(jù)結(jié)構(gòu)來操作。由于程序中的orig字符串存儲(chǔ)的是xmlEntity節(jié)點(diǎn)內(nèi)的字符串信息，所以在觸發(fā)漏洞的代碼這個(gè)例子中，此處存儲(chǔ)的字符串為：
'XX';
toascii(addr); // ns->href
toascii(addr); // ns->prefix
'XXXX' // ns->_private
'XXXX' // ns->context
' xmlns:xsl=\'http://www.w3.org/1999/XSL/Transform\' terminate=\'yes\'/>
而在宏中，會(huì)把這串字符串當(dāng)作xmlNs類型來操作。
圖6 xmlNs的數(shù)據(jù)結(jié)構(gòu)
因此可以通過此漏洞達(dá)到地址泄漏的目的?？梢宰⒁獾剑?dāng)宏將字符串當(dāng)作xmlNs節(jié)點(diǎn)來處理時(shí)，代碼中轉(zhuǎn)換為ascii碼的addr就可以被當(dāng)作比較的字符串指針(href)來處理(詳細(xì)信息見圖4)所以我們可以將任何可以轉(zhuǎn)化為ascii碼的地址寫入href指針，從而讓這些指針?biāo)赶虻淖址c“http://www.w3.org/1999/XSL/Transform”進(jìn)行比較。
如果比較結(jié)果為真，則繼續(xù)后續(xù)操作，否則，libxslt將返回一個(gè)可被javascript接收的error信息。攻擊者通過接受的error信息，就可判定輸入的地址是否有指定的字符串，再結(jié)合大量的數(shù)據(jù)填充，就可以打到地址泄漏的目的。(詳見“三、利用方式”)#p#
3. 調(diào)試過程
調(diào)試過程在nexus 7+android4.3上進(jìn)行。
由于在webkit解析xsl文件時(shí)，如果標(biāo)簽為
圖7 程序在xmlParseEntityDecl停下時(shí)的狀態(tài)
myDoc節(jié)點(diǎn)：0x400d9768最終程序崩潰時(shí)，調(diào)用棧中會(huì)顯示是由于處理這個(gè)對(duì)象而導(dǎo)致崩潰。
Input：0x59988c18通過查看input信息，可知對(duì)xsl對(duì)象所解析到那個(gè)節(jié)點(diǎn)。
查看input信息：
圖8 Input中的信息
圖9 程序的解析狀態(tài)
如圖9顯示，正在解析!ENTITY節(jié)點(diǎn)。(base表示所解析的字符串，cur表示當(dāng)前解析到的位置。)
函數(shù)entityDecl會(huì)創(chuàng)建引發(fā)錯(cuò)誤的ENTITY對(duì)象：
圖10 xmlEntity節(jié)點(diǎn)的創(chuàng)建(此時(shí)節(jié)點(diǎn)的數(shù)據(jù)類型為xmlNode)
如圖10中所示，新生成的next節(jié)點(diǎn)，為通過entityDecl函數(shù)所得到的entity節(jié)點(diǎn)(type=0×11，0×11表示為entity節(jié)點(diǎn)，為圖2中XML_ENTITY_DECL的實(shí)際值)。此時(shí)此節(jié)點(diǎn)的compression字段(在xmlEntity中此字段為orig字段)為0。
函數(shù)xmlParseEntityValue會(huì)將節(jié)點(diǎn)中的字符串存儲(chǔ)于orig字符串指針中。
圖11 獲取xmlEntity節(jié)點(diǎn)中的字符串信息
如圖11所示，程序?qū)?ENTITY節(jié)點(diǎn)中解析出的字符串傳給了orig。(input中的cur(當(dāng)前值)已向后移動(dòng)，而之前的部分存入了orig中)
之后，函數(shù)會(huì)將orig賦值給xmlEntity對(duì)象的orig。
圖12 將字符串存入xmlEntity的orig字段中
函數(shù)通過cur對(duì)目標(biāo)xmlEntity節(jié)點(diǎn)的orig字段進(jìn)行賦值。
圖13 將之前出問題的節(jié)點(diǎn)轉(zhuǎn)換為xmlEntity類型
如圖13所示，被賦值的cur正是之前創(chuàng)建的xmlEntity節(jié)點(diǎn)。
而當(dāng)程序運(yùn)行到cur->orig=orig時(shí)，目標(biāo)位置指針被重置：
圖14 字符串的傳入
如圖14所示，此時(shí)的compission字段被置為orig指針，存儲(chǔ)著可控的對(duì)象。而當(dāng)對(duì)此節(jié)點(diǎn)進(jìn)行namespace比較時(shí)，節(jié)點(diǎn)會(huì)類型轉(zhuǎn)換為xmlNode類型，而xmlEntity->orig字符串字段則會(huì)被當(dāng)成xmlNs類型來解釋，最終達(dá)到任意地址比較的操作。
圖15 程序崩潰時(shí)的狀態(tài)
如圖15所示，程序最終在字符串比較時(shí)發(fā)生段錯(cuò)誤，此時(shí)的棧中xsltParseTemplateContext的第二個(gè)參數(shù)，正是為我們?cè)趚mlParseEntityDecl停下時(shí)，myDoc所指向的地址。#p#
三、利用方式
1.向內(nèi)存中填充330頁的寫有namespace信息的頁。通過大量的數(shù)據(jù)填充，在觸發(fā)漏洞時(shí)就有更大的可能匹配成功，只有匹配成功，才能進(jìn)一步的地址泄漏。如果觸發(fā)漏洞時(shí)的addr值指向未被分配的頁，則會(huì)出現(xiàn)段錯(cuò)誤導(dǎo)致程序崩潰。
圖16 內(nèi)存填充
圖17 填充namespace信息
2.通過漏洞，可以在xsl對(duì)象生成時(shí)，修改href指針的值(詳見圖6)，將地址改為一個(gè)在填充過程中，有很大幾率會(huì)被填充到的地址。
圖18 漏洞利用代碼1
圖19 漏洞利用代碼2
3.函數(shù)內(nèi)部會(huì)自動(dòng)對(duì)xsl對(duì)象的namespace指針進(jìn)行匹配，以確定xsl對(duì)象是否為一個(gè)合法的xsl元素。如果為非法元素，則會(huì)被javascript捕獲到異常。
圖20 javascript可獲取的異常狀態(tài)
4.若進(jìn)入if，則字符串匹配成功，之后進(jìn)入二分法查找具體頁的過程，addr為觸發(fā)漏洞時(shí)所寫入的地址。若進(jìn)入else，將猜測(cè)的地址addr進(jìn)行變化，再次進(jìn)行比較過程(此函數(shù)名即為find_spray_addr進(jìn)入else后，則會(huì)迭代查找地址)。
5.二分法查找：
a.將填充的330頁數(shù)據(jù)的前一半(165頁)數(shù)據(jù)進(jìn)行清空。
b.再次調(diào)用漏洞，判斷是否發(fā)生異常，若異常，則addr所指向的地址在前一半填充的頁中。否則，addr所指向的地址在后一半填充的頁中。
c.繼續(xù)對(duì)前一半或后一半進(jìn)行a、b兩步，直到僅剩一頁時(shí)，則可判定addr指向的是此頁中的地址。
圖21 二分法查找addr所在頁的代碼1
圖22 二分法查找addr所在頁的代碼2
6.通過獲取頁信息，即可得到一個(gè)泄露的內(nèi)存地址addr以及周圍4mb的可控內(nèi)存，達(dá)到本階段的漏洞利用目的。
當(dāng)前文章：Hacking Team安卓瀏覽器攻擊過程中的漏洞分析Stage0
網(wǎng)頁鏈接：http://www.5511xx.com/article/dpjdops.html
