最近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支持格式模块libarchive\archive_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 < numFolders; i++) {
Line 2152 if (parse_7zip_uint64(a, &(f[i].numUnpackStreams)) < 0)
Line 2153 return (-1);
Line 2154 if (UMAX_ENTRY < f[i].numUnpackStreams)
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 < numFolders; 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 < f[i].numUnpackStreams; 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”有个最大值：
也就是说，要让“unpack_streams”变量溢出，我们只需要做个7-Zip文件——文件夹数量“numFolders”大于42，给“numUnpackStreams”填入足够的值就行。
在2166-2171行，溢出的值在calloc函数中是作为大小参数的。这里最有趣的部分在“ss->unpackSizes”。后面2187-2194行，64位无符号整数(最大)是基于每个文件夹的“numFolders”和“numUnpackStreams”从文件中读取的，并存储到缓冲区“unsizes”中——2177行“ss->unpackSizes”就能导致缓冲区溢出。
受影响的软件很多
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)在所有应用中部署到位，恐怕还是得花很多时间的。
(责任编辑：宋编辑)
