浅谈zip格式处理逻辑漏洞

前言：zip压缩格式应用广泛，各个平台都有使用，Windows平台使用来压缩文件，Android平台使用来作为apk文件的格式。由于zip文件格式比较复杂，在解析zip文件格式时，如果处理不当，可能导致一些有意思的逻辑漏洞，本篇文章将挑选有意思的漏洞进行解析。

一、文件扩展名欺骗漏洞



很早之前，国外安全研究人员爆料Winrar 4.x版本存在文件扩展名欺骗漏洞，黑客可以通过该漏洞诱骗受害者执行恶意程序。该漏洞的主要原理是：Winrar在文件预览和解压缩显示文件名使用的是不同结构体的字段导致的。

1.1 zip格式文件的结构


在了解漏洞的原理前，先熟悉下zip格式的文件结构。

如果一个压缩包文件里有多个文件，可以认为每个文件都是被单独压缩，然后再拼成一起。

一个 ZIP 文件由三个部分组成：压缩源文件数据区+压缩源文件目录区+压缩源文件目录结束标志，如下图：

图片：2015102103080233127.png

1）文件头（压缩源文件目录区）在文件末尾，即图1中的File Header，记录了索引段的偏移、大小等等。

2）数据段（压缩源文件数据区）在文件开头，即图1中的Local Header，记录了数据的一些基本信息，可以用来跟File Header中记录的数据进行比较，保证数据的完整性。

3）Local Header还包含了文件被压缩之后的存储区，即图1中的Data区域。

4）图2和图3为Local Header（图2中的ZIPFILERECORD）和File Header（图3中的ZIPDIRENTRY）的数据对比，两者数据是一致的。

图片：2015102103080233127.png

图片：2015102103080233127.png

1.2 漏洞产生原因


Winrar在文件预览的时候使用的是ZIPDIRENTRY下面的deFileName字段来显示文件名，解压缩的时候使用的是ZIPFILERECORD下面的frFileName字段来显示文件名。如果将deFileName字段文件扩展名改成jpg、gif等图片的文件扩展名，可以欺骗用户运行恶意程序。

Winrar文件预览示意图：

图片：2015102103080233127.png

用户看到的是jpg图片，打开的确实exe文件，真坑啊！

Winrar解压缩文件示意图：

图片：2015102103080233127.png

解压缩之后显示的exe，两处显示的不一样。

二、Android Master Key漏洞



之前，国外安全研究人员爆出第三个Android Master Key漏洞，该漏洞的主要原理是：android在解析Zip包时，没有校验ZipEntry和Header中的FileNameLength是否一致。

2.1 zip文件格式的结构


在了解漏洞的原理前，还是先熟悉下zip格式的文件结构。

如果一个压缩包文件里有多个文件，可以认为每个文件都是被单独压缩，然后再拼成一起。

一个 ZIP 文件由三个部分组成：压缩源文件数据区+压缩源文件目录区+压缩源文件目录结束标志，如图1所示：

1）文件头（压缩源文件目录区）在文件末尾，即图1中的File Header，记录了索引段的偏移、大小等等。

2）数据段（压缩源文件数据区）在文件开头，即图1中的Local Header，记录了数据的一些基本信息，可以用来跟File Header中记录的数据进行比较，保证数据的完整性。

3）Local Header还包含了文件被压缩之后的存储区，即图1中的Data区域。

4）图2和图3为Local Header（图2中的ZIPFILERECORD）和File Header（图3中的ZIPDIRENTRY）的数据对比，两者数据是一致的。

图片：2015102103080233127.png

图片：2015102103080233127.png

2.2 漏洞产生原因


先来看一下是如何定位到Local Header中的Data数据：

off64_t dataOffset = localHdrOffset + kLFHLen + get2LE(lfhBuf + kLFHNameLen) +

Data的偏移是通过Header的起始偏移+Header的大小（固定值）+Extra data的大小+文件名的大小，如下图

图片：2015102103080233127.png

回头看一下，java在获取Data偏移的处理，在读取Extra data的长度的时候，它已经预存了文件名在FileHeader中的长度。

// We don't know the entry data's start position.
// All we have is the position of the entry's local
// header. At position 28 we find the length of the
// extra data. In some cases this length differs
// from the one coming in the central header.
RAFStream rafstrm = new RAFStream(raf, entry.mLocalHeaderRelOffset + 28);
DataInputStream is = new DataInputStream(rafstrm);
int localExtraLenOrWhatever =

漏洞就在这里产生了，如果Local Header中的FileNameLength被设成一个大数，并且FileName的数据包含原来的数据，File Header中的FileNameLength长度不变，那么底层C++运行和上层Java运行就是不一样的流程。

C++ Header 64k Name Data
+--------> +----------------------> +---------->
length=64k classes.dex dex35A... dex35B...
+--------> +---------> +---------->

如上面所示，底层C++的执行会读取64k的FileName长度，而Java层由于是读取File Header中的数据，FileName的长度依旧是11，于是Java层校验签名通过，底层执行会执行恶意代码。