最近Libarchive又被曝出存在安全漏洞——Libarchive是个开源压缩库，为各种不同文件档案格式准备的。Libarchive的应用范围非常广，因此，所以大量项目自然也就受到了影响，如Debian Linux、FreeBSD，还有诸多文件压缩工具。

是什么样的安全漏洞？

思科的研究人员说，这次发现的漏洞包括：Libarchive处理7-Zip文件时可能发生整数溢出的问题（CVE-2016-4300），还有处理Mtree文件时缓冲区溢出（CVE-2016-4301）、处理RAR文件时堆溢出（CVE-2016-4302）。很显然，这些都是相当危险的安全漏洞，攻击者可利用这些漏洞在感染的设备上远程执行代码。

比如说，攻击者可利用整数溢出漏洞做个7-Zip文件，用户只要用Libarchive库相关软件来处理7-Zip文件就可以造成内存溢出以及恶意代码执行。相关7-Zip支持格式模块libarchivearchive_read_support_format_7zip.c，存在漏洞的代码如下：

(...)

#define UMAX_ENTRY ARCHIVE_LITERAL_ULL(100000000)

(...)

Line 2129 static int

Line 2130 read_SubStreamsInfo(struct archive_read *a, struct _7z_substream_info *ss,

Line 2131 struct _7z_folder *f, size_t numFolders)

Line 2132 {

Line 2133 const unsigned char *p;

Line 2134 uint64_t *usizes;

Line 2135 size_t unpack_streams;

Line 2136 int type;

Line 2137 unsigned i;

Line 2138 uint32_t numDigests;

(...)

Line 2149 if (type == kNumUnPackStream) {

Line 2150 unpack_streams = 0;

Line 2151 for (i = 0; i

Line 2152 if (parse_7zip_uint64(a, &(f[i].numUnpackStreams)) <0)

Line 2153 return (-1);

Line 2154 if (UMAX_ENTRY

Line 2155 return (-1);

Line 2156 unpack_streams += (size_t)f[i].numUnpackStreams;

^^^^^^^^^ ---- INTEGER OVERFLOW

Line 2157 }

Line 2158 if ((p = header_bytes(a, 1)) == NULL)

Line 2159 return (-1);

Line 2160 type = *p;

Line 2161 } else

Line 2162 unpack_streams = numFolders;

Line 2163

Line 2164 ss->unpack_streams = unpack_streams;

Line 2165 if (unpack_streams) {

Line 2166 ss->unpackSizes = calloc(unpack_streams,

^^^^^^^^^ ---- ALLOCATION BASED ON OVERFLOWED INT

Line 2167 sizeof(*ss->unpackSizes));

Line 2168 ss->digestsDefined = calloc(unpack_streams,

Line 2169 sizeof(*ss->digestsDefined));

Line 2170 ss->digests = calloc(unpack_streams,

Line 2171 sizeof(*ss->digests));

Line 2172 if (ss->unpackSizes == NULL || ss->digestsDefined == NULL ||

Line 2173 ss->digests == NULL)

Line 2174 return (-1);

Line 2175 }

Line 2176

Line 2177 usizes = ss->unpackSizes;

Line 2178 for (i = 0; i

Line 2179 unsigned pack;

Line 2180 uint64_t sum;

Line 2181

Line 2182 if (f[i].numUnpackStreams == 0)

Line 2183 continue;

Line 2184

Line 2185 sum = 0;

Line 2186 if (type == kSize) {

Line 2187 for (pack = 1; pack

Line 2188 if (parse_7zip_uint64(a, usizes) <0) ^^^^^^^^^ ---- BUFFER OVERFLOW

Line 2189 return (-1);

Line 2190 sum += *usizes++;

Line 2191 }

Line 2192 }

Line 2193 *usizes++ = folder_uncompressed_size(&f[i]) - sum;

Line 2194 }

在2149-2157行，针对所有的“folders”，计算“numUnpackStreams”的总数，结果随后就存储到“unpack_streams”变量中。这个位置的“size_t”意思是说，在x86平台上此变量是个32位无符号整数。注意，“numUnpackStreams”有个最大值：

UMAX_ENTRY 100000000

也就是说，要让“unpack_streams”变量溢出，我们只需要做个7-Zip文件——文件夹数量“numFolders”大于42，给“numUnpackStreams”填入足够的值就行。

在2166-2171行，溢出的值在calloc函数中是作为大小参数的。这里最有趣的部分在“ss->unpackSizes”。后面2187-2194行，64位无符号整数（最大）是基于每个文件夹的“numFolders”和“numUnpackStreams”从文件中读取的，并存储到缓冲区“unsizes”中——2177行“ss->unpackSizes”就能导致缓冲区溢出。

另外两个漏洞，详细参见思科Talos团队的报告（点击这里）。

　　受影响的软件很多

Libarchive是2004年的时候专门为FreeBSD所推的压缩库。此后，Libarchive很快就吸引了不少开发者，这些开发者就将Libarchive移植到了其他操作系统或融合到自己的软件产品里。Libarchive吸引开发者的地方在于，它支持实时访问许多压缩文件格式，比如7z、zip、cpio、pax、rar、cab等。

所以这次被曝出的安全漏洞间接影响到了大量项目和产品。Libarchive本身或者包含Libarchive的软件读取这些恶意压缩文件，黑客就能在用户的系统中执行恶意代码。你知道哪些软件会用到Libarchive吗？实际上不光是压缩/解压工具可能会采用Libarchive，如本文开头所言，这还是个系统级的库，各种包管理器、文件浏览器，甚至反病毒软件都会用到它。

想象一下，你用的反病毒软件或者包管理器，代码中本身就包含Libarchive——用以实时读取归档文件。所有的反病毒软件都需要对压缩文件先解压缩，这样才能查看里面是否有恶意程序；而包管理器的作用是下载、解压、安装软件。那么攻击者完全可以利用Libarchive的漏洞，构建恶意压缩文件，感染PC。

思科团队表示：

“导致Libarchive这些漏洞的根源在于没有正确进行输入验证——那些从压缩文件读取到的数据。悲剧的是，这类编程错误总是反复不停地出现。”

在昨天发布的博客中，思科Talos团队宣布，已经和Libarchive团队合作发布了一系列的补丁。但因为Libarchive的存在性的确相当广泛，开发者要将最新版（v3.2.1）在所有应用中部署到位，恐怕还是得花很多时间的。

* 参考来源：Softpedia，FB小编欧阳洋葱编译，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）