最近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）