【前言】

日前谷歌公開了一個今年1月份更新的漏洞。這個漏洞修復了一個存在于Android 5.1版本以下圖片渲染的問題，可以查看相關鏈接。

9patch是Android上特有的一種圖片格式，就是在普通的png圖片的基礎了增加了一些像素的邊框，使之具有可隨意拉伸、縮放的功能。

【9patch文件格式概述】

前面說到9patch文件是一種特殊png圖片，我們先來看下png文件結構。

 

 

在png文件的起始處是一個被稱為signature的東西，即文件簽名，很多人把它叫做文件頭，長度為8個字節(jié)，這8個字符的值是固定的。

 

 

在signature之后是一個chunk塊序列，每個chunk塊的大小都是不定的，里面存儲著圖像數(shù)據(jù)，chunk塊的結構如下：

 

 

偽代碼描述如下：

 

 

在chunk的起始處是chunk長度，被定義為4字節(jié)大端整數(shù)。這個chunk長度僅僅是chunkdata的長度，不包括自身、type和crc的長度，因此整個chunk塊的長度還需要加上這三個域的大小。之后一個4字節(jié)的字符序列，只能由英文字符組成，表示chunk塊的類型。隨后chunk數(shù)據(jù)部分，長度由開始的length指定，當length為0時這個域可以不存在。最后是整個塊的CRC校驗碼。再往后?就是下一個chunk塊了啊。

下面說下本文的主角9patch文件。它是包含類型為”npTc”在chunk的png文件?？聪耮oogle官方的定義(已過濾不相關的若干代碼)：

 

 

來看一個普通的9patch文件

 

 

這個9patch文件的npTc塊位于第一個IHDR塊之后，chunk長度為0x20，data域的值都為0，圖中指出了numXDivs、numYDivs和numColors的位置，依次可以推出其他數(shù)據(jù)域的值。#p#

【漏洞分析】

(懶得看的話直接跳到最后看結論)。

在5.1版本上加載一張盡心構造的9patch圖片，就會導致進程Crash，如下圖所示。

 

 

看錯誤是引用了不合法的地址，看google的補丁吧：

 

 

 

 

補丁一共有兩處：

1. chunk塊中numXDivs、numYDivs、numColors三個變量的定義改成了無符號型

2. npTc塊的peek函數(shù)中的斷言改成了判斷不等再返回

numXDivs、numYDivs、numColors這三個變量什么要改成無符號型，為什么不能是負的，如果是負的會怎么樣，帶著問題再分析，看看哪里用到了這三個值。

 

 

從這里可以看出xDivsOffset是Res_png_9patch結構的長度，這是一個常量，一般來說是0x20。yDivsOffset的值在此基礎上增加大小為numXDivs的int數(shù)組的長度，colorsOffset的值在yDivsOffset的基礎上增加大小為numYDivs的int數(shù)組的長度。再回溯：

 

 

 

 

而yDivsOffset和colorsOffset以決定了yDivs和colors兩個數(shù)組的地址，那只要精心構造numXDivs、numYDivs就可以在一定范圍內(nèi)訪問其他任意的內(nèi)存，，看來剛才報的引用非法地址應該就是這里了。

還有一處引用了numXDivs、numYDivs、numColors的地方。

 

 

再看看調(diào)用serializedSize的地方：

 

 

這里用serializedSize()的返回值和length進行比較，而numXDivs、numYDivs、numColors可以為負，影響了serializedSize正常的計算，觸發(fā)斷言，中斷程序。

【總結】

分析了這么多，來總結漏洞成因。

Res_png_9patch結構中定義了numXDivs、numYDivs、numColors的類型為有符號數(shù)，當它們得到負值時會影響yDivsOffset、colorsOffset和serializedSize的取值，從而導致堆溢出，現(xiàn)象就是數(shù)組越界。

 

 

將之前文件中的numXDivs、numYDivs、numColors三位其中某一位修改為負數(shù)(即大于0x80)即可驗證此漏洞。

【檢測方案】

掌握這個漏洞的細節(jié)以后要防就很容易了，只要遍歷png文件的所有chunk塊，針對其中的npTc塊進行檢測，判斷numXDivs、numYDivs、numColors是否為負，只要其中有一個為負則可判定為惡意文件，相關檢測代碼如下：