【前言】
日前谷歌公开了一个今年1月份更新的漏洞。这个漏洞修复了一个存在于Android 5.1版本以下图片渲染的问题,可以查看相关链接。
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是否为负,只要其中有一个为负则可判定为恶意文件,相关检测代码如下: