Android 9patch圖片解析堆溢出漏洞分析
責編：admin ｜2015-05-29 09:02:46近日，google公開了一個2015年1月份更新的漏洞。這個漏洞修復了一個存在于Android 5.1版本以下圖片渲染的問題，查看地址：https://code.google.com/p/google-security-research/issues/detail?id=234
9patch是Android上特有的一種圖片格式，就是在普通的png圖片的基礎了增加了一些像素的邊框，使之具有可隨意拉伸、縮放的功能。
9patch文件格式概述
前面說到9patch文件是一種特殊png圖片，我們先來看下png文件結構。
在png文件的起始處是一個被稱為signature的東西，即文件簽名，很多人把它叫做文件頭，長度為8個字節，這8個字符的值是固定的。
在signature之后是一個chunk塊序列，每個chunk塊的大小都是不定的，里面存儲著圖像數據，chunk塊的結構如下：
偽代碼描述如下：
在 chunk的起始處是chunk長度，被定義為4字節大端整數。這個chunk長度僅僅是chunkdata的長度，不包括自身、type和crc的長 度，因此整個chunk塊的長度還需要加上這三個域的大小。之后一個4字節的字符序列，只能由英文字符組成，表示chunk塊的類型。隨后chunk數據 部分，長度由開始的length指定，當length為0時這個域可以不存在。最后是整個塊的CRC校驗碼。再往后？就是下一個chunk塊了啊。
下面說下本文的主角9patch文件。它是包含類型為”npTc”在chunk的png文件。看下google官方的定義（已過濾不相關的若干代碼）：
來看一個普通的9patch文件
這個9patch文件的npTc塊位于第一個IHDR塊之后，chunk長度為0x20，data域的值都為0，圖中指出了numXDivs、numYDivs和numColors的位置，依次可以推出其他數據域的值。
漏洞分析
(懶得看的話直接跳到最后看結論）。
在5.1版本上加載一張盡心構造的9patch圖片，就會導致進程Crash，如下圖所示。
看錯誤是引用了不合法的地址，看google的補丁吧：
補丁一共有兩處：
1. chunk塊中numXDivs、numYDivs、numColors三個變量的定義改成了無符號型
2. npTc塊的peek函數中的斷言改成了判斷不等再返回
numXDivs、numYDivs、numColors這三個變量什么要改成無符號型，為什么不能是負的，如果是負的會怎么樣，帶著問題再分析，看看哪里用到了這三個值。
從這里可以看出xDivsOffset是Res_png_9patch結構的長度，這是一個常量，一般來說是0x20。yDivsOffset的值 在此基礎上增加大小為numXDivs的int數組的長度，colorsOffset的值在yDivsOffset的基礎上增加大小為numYDivs的 int數組的長度。再回溯：
而yDivsOffset和colorsOffset以決定了yDivs和colors兩個數組的地址，那只要精心構造numXDivs、numYDivs就可以在一定范圍內訪問其他任意的內存，，看來剛才報的引用非法地址應該就是這里了。
還有一處引用了numXDivs、numYDivs、numColors的地方。
再看看調用serializedSize的地方：
這里用serializedSize()的返回值和length進行比較，而numXDivs、numYDivs、numColors可以為負，影響了serializedSize正常的計算，觸發斷言，中斷程序。
總結
分析了這么多，來總結漏洞成因。
Res_png_9patch結構中定義了numXDivs、numYDivs、numColors的類型為有符號數，當它們得到負值時會影響yDivsOffset、colorsOffset和serializedSize的取值，從而導致堆溢出，現象就是數組越界。
將之前文件中的numXDivs、numYDivs、numColors三位其中某一位修改為負數（即大于0x80）即可驗證此漏洞。
檢測方案
掌握這個漏洞的細節以后要防就很容易了，只要遍歷png文件的所有chunk塊，針對其中的npTc塊進行檢測，判斷numXDivs、numYDivs、numColors是否為負，只要其中有一個為負則可判定為惡意文件，相關檢測代碼如下：
