转载

开源压缩库Librachive曝高危漏洞，影响Debian Linux、FreeBSD等大量产品

最近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”有个最大值：

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团队的报告（点击这里）。

开源压缩库Librachive曝高危漏洞，影响Debian Linux、FreeBSD等大量产品

受影响的软件很多

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）

原文 http://www.freebuf.com/news/107566.html

正文到此结束