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

2016-06-23 278746人围观 ,发现 3 个不明物体 漏洞资讯

The-Unarchiver38341300.jpg

最近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团队的报告(点击这里)。

7ziplogo.svg.png

受影响的软件很多

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)

这些评论亮了

发表评论

已有 3 条评论

取消
Loading...
css.php