谷歌公开1月更新漏洞，修复Android5.1以下图片渲染问题

【前言】

日前谷歌公开了一个今年1月份更新的漏洞。这个漏洞修复了一个存在于.1版本以下图片渲染的问题，可以查看相关链接。

是上特有的一种图片格式，就是在普通的png图片的基础了增加了一些像素的边框，使之具有可随意拉伸、缩放的功能。

【文件格式概述】

前面说到文件是一种特殊png图片，我们先来看下png文件结构。

在png文件的起始处是一个被称为的东西，即文件签名，很多人把它叫做文件头，长度为8个字节，这8个字符的值是固定的。

在之后是一个chunk块序列，每个chunk块的大小都是不定的，里面存储着图像数据，chunk块的结构如下：

伪代码描述如下：

在chunk的起始处是chunk长度，被定义为4字节大端整数。这个chunk长度仅仅是的长度，不包括自身、type和crc的长度，因此整个chunk块的长度还需要加上这三个域的大小。之后一个4字节的字符序列，只能由英文字符组成，表示chunk块的类型。随后chunk数据部分，长度由开始的指定，当为0时这个域可以不存在。最后是整个块的CRC校验码。再往后?就是下一个chunk块了啊。

下面说下本文的主角文件。它是包含类型为”npTc”在chunk的png文件。看下官方的定义(已过滤不相关的若干代码)：

来看一个普通的文件

这个文件的npTc块位于第一个IHDR块之后，chunk长度为0x20，data域的值都为0，图中指出了、和的位置，依次可以推出其他数据域的值。

【漏洞分析】

(懒得看的话直接跳到最后看结论)。

在5.1版本上加载一张尽心构造的图片，就会导致进程Crash，如下图所示。

看错误是引用了不合法的地址，看的补丁吧：

补丁一共有两处：

1. chunk块中、、三个变量的定义改成了无符号型

2. npTc块的peek函数中的断言改成了判断不等再返回

、、这三个变量什么要改成无符号型，为什么不能是负的，如果是负的会怎么样，带着问题再分析，看看哪里用到了这三个值。

从这里可以看出是结构的长度，这是一个常量，一般来说是0x20。的值在此基础上增加大小为的int数组的长度，的值在的基础上增加大小为的int数组的长度。再回溯：

而和以决定了yDivs和两个数组的地址，那只要精心构造、就可以在一定范围内访问其他任意的内存，，看来刚才报的引用非法地址应该就是这里了。

还有一处引用了、、的地方。

再看看调用的地方：

这里用的返回值和进行比较，而、、可以为负，影响了正常的计算，触发断言，中断程序。

【总结】

分析了这么多，来总结漏洞成因。

结构中定义了、、的类型为有符号数，当它们得到负值时会影响、和的取值，从而导致堆溢出，现象就是数组越界。

将之前文件中的、、三位其中某一位修改为负数(即大于0x80)即可验证此漏洞。

【检测方案】

掌握这个漏洞的细节以后要防就很容易了，只要遍历png文件的所有chunk块，针对其中的npTc块进行检测，判断、、是否为负，只要其中有一个为负则可判定为恶意文件，相关检测代码如下：

chunk 文件 长度 一个 png 漏洞