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

一、文件扩展名欺骗漏洞


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

1.1 zip格式文件的结构

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

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

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

enter image description here

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)的数据对比,两者数据是一致的。

enter image description here

enter image description here

1.2 漏洞产生原因

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

Winrar文件预览示意图:

enter image description here

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

Winrar解压缩文件示意图:

enter image description here

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

二、Android Master Key漏洞


之前,国外安全研究人员爆出第三个Android Master Key漏洞,该漏洞的主要原理是:android在解析Zip包时,没有校验ZipEntryHeader中的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)的数据对比,两者数据是一致的。

enter image description here

enter image description here

2.2 漏洞产生原因

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

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

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

enter image description here

回头看一下,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 dex\035\A... dex\035\B... 
+--------> +---------> +----------> 

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