Hacking Team安卓瀏覽器攻擊過程中的漏洞分析Stage0

作者：MarcusAurelius 2015-09-23 13:38:42

Hacking team今年爆出了針對android4.0.x-4.3.x android瀏覽器的漏洞攻擊利用代碼。該漏洞攻擊代碼，通過連續利用多個瀏覽器與內核漏洞，完成通過javascript向虛擬內存寫數據，執行代碼，提升至root權限，并最終達到向目標手機中植入惡意程序的目的。

一、漏洞簡介

該利用過程分為5個復雜的Stage，本文首先分析了第1個Stage，即Stage0。攻擊代碼的Stage0階段通過一個0Day地址泄露漏洞，為后續數據填充操作完成定位地址定位的任務。此漏洞位于android-src\external\libxslt模塊中。

二、漏洞詳細信息

概述

Stage0利用的0Day漏洞原理如下：

該漏洞屬于未經正確性檢查，就直接錯誤地進行強制類型轉換，從而導致一個用于內存讀(實際用于字符串比較)的指針可以被操控。漏洞利用的思路是：通過在JS分配的大片內存空間中，填充字符串：http://www/w3.org/1999/XSL/Transform，程序的后續邏輯會將該字符串會與那個可控內存指針所指向的字符串進行比較，一旦字符串對比不成功，則javascript的一個對象會記錄下“Error”,由于指針所指向的地址是可控制的，一旦發現 “Error”，就重新調整地址，直到沒有發生Error，這樣就得到了javascript開辟的可控空間的內存地址信息。

1. 數據結構背景

圖1展示了hacking team所使用的觸發漏洞代碼：

圖1 漏洞觸發代碼與其內存結構

在瀏覽器中，我們可以使用javascript引用如圖1所示的xsl文件，通過此文件，即可引發stage0所使用的漏洞。圖1中的xsl語句，在libxml2解析后，會形成如圖1中右圖所示結構。其中，xsl描述的cdent節點，即為觸發漏洞的ENTITY類型節點。

此漏洞發生在瀏覽器引擎對xsl文件的解析過程中。因此，我們先簡述一下圖1中代碼，與右圖節點的對應關系。右圖的myDoc節點為虛的根節點，在左圖xsl描述中并沒有對應。xsl描述的最外層adoc和ata節點，同為根節點的下的一級子節點，由于adoc是第一個子節點，被myDoc的數據結構中得children指針指向，ata則被adoc的next指針指向。同理，x節點，cdent節點和y節點，同為adoc的子節點一級，形成如上圖所示結構。#p#

2. 漏洞成因

程序出現異常的根本原因是由于libxslt在對圖1中的cdent(xmlEntity類型)節點進行操作時，并未對此節點的類型進行比較，導致對cdent節點進行了不正確的類型轉換(轉換為xmlNode類型)，并對轉換后的節點進行了非法操作。libxslt(android瀏覽器在對xsl進行解析時所使用的模塊)在對xsl操作的過程中，會對大部分節點的namespace進行比較，判斷節點是否為一個合法的xsl節點。

但當節點類型為xmlEntity類型時，由于xmlEntity沒有ns(用來比較namespace信息的數據結構)字段，所以不對xmlEntity類型進行比較namespace操作(xmlEntity類型、xmlNode類型的詳細信息請看圖5)。而libxslt在判斷節點類型是否為xmlEntity時，libxslt的判斷并不完全，最終導致xmlEntity可被轉換為xmlNode進行操作。從而引發程序崩潰。

圖2 未對所有節點的類型進行判斷

觸發崩潰的第一步，是由于對節點類型的比較不完全導致的。libxslt在成功構建節點樹(如圖2中右圖)后，會循環對myDoc的子節點進行namespace比較操作，圖2中左側代碼，是在循環中當對當前節點的所有操作完成時，將循環操作中的節點指針指向下一個需要操作的節點的代碼。根據圖2中第4967行的代碼，我們可以發現，libxslt是希望當目標節點子節點或next節點的類型不為xmlEntity類型時，將目標節點子節點或next節點賦值給cur指針，再由cur指針進入下一次循環。但是，libxslt只對cur指針的第一個子節點進行了數據類型的比較操作，并沒有對cur指針的next節點進行數據類型的比較。而在我們構建的節點結構中，cdent(xmlEntity類型)節點，正是被x的next指針指向的，導致cdent節點不正確的進入了循環。

圖3 對namespace進行比較的函數

觸發崩潰的第二步，是xmlEntity節點被轉換為xmlNode節點。圖3為第一步中所說的循環的開始位置(圖3代碼的4893行)，我們可以清晰的看到第一步所用的cur指針的數據類型為xmlNode類型。而第一步的xmlEntity類型被賦值給了xmlNode類型的指針，這就導致了類型轉換的錯誤。

圖4 IS_XSLT_ELEM宏的定義

觸發崩潰的第三步，是對不正確的數據類型進行了非法操作。圖4為圖3中IS_XSLT_ELEM宏的展開。IS_XSLT_ELEM宏的操作是比較節點的namespace，判斷xmlNode結構體中的ns字段(此字段指向一個xmlNs的數據類型)中的href字段所指向的地址是否存儲了字符串“http://www.w3.org/1999/XSL/Transform”。

圖5 相互轉換的兩種數據類型

當IS_XSLT_ELEM宏的輸入參數為一個xmlEntity類型時，宏就會將orig字符串當作xmlNs類型的數據結構來操作。由于程序中的orig字符串存儲的是xmlEntity節點內的字符串信息，所以在觸發漏洞的代碼這個例子中，此處存儲的字符串為：

'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\'/>

而在宏中，會把這串字符串當作xmlNs類型來操作。

圖6 xmlNs的數據結構

因此可以通過此漏洞達到地址泄漏的目的。可以注意到，當宏將字符串當作xmlNs節點來處理時，代碼中轉換為ascii碼的addr就可以被當作比較的字符串指針(href)來處理(詳細信息見圖4)所以我們可以將任何可以轉化為ascii碼的地址寫入href指針，從而讓這些指針所指向的字符串與“http://www.w3.org/1999/XSL/Transform”進行比較。

如果比較結果為真，則繼續后續操作，否則，libxslt將返回一個可被javascript接收的error信息。攻擊者通過接受的error信息，就可判定輸入的地址是否有指定的字符串，再結合大量的數據填充，就可以打到地址泄漏的目的。(詳見“三、利用方式”)#p#

3. 調試過程

調試過程在nexus 7+android4.3上進行。

由于在webkit解析xsl文件時，如果標簽為