Summary: | Crafted gzip archive causes tar(1) to exhaust all your memory | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Robert Clausecker <fuz> | ||||
Component: | misc | Assignee: | Xin LI <delphij> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Some People | CC: | emaste, junovitch, secteam, tablosazi.farahan, vsasjason | ||||
Priority: | --- | ||||||
Version: | 10.2-RELEASE | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Can you report this to the libarchive upstream as well? https://github.com/libarchive/libarchive Issue #660 has been reported against the libarchive. https://github.com/libarchive/libarchive/issues/660 This has been fixed upstream: https://github.com/libarchive/libarchive/commit/6e06b1c89dd0d16f74894eac4cfc1327a06ee4a0 Actually I am going to reopen. The last libarchive release was in 2013 (https://github.com/libarchive/libarchive/releases) so we will have to pull fixes like this in. It can probably be combined with the security fixes for libarchive in bug 206386. A commit references this bug: Author: delphij Date: Tue Feb 23 07:13:22 UTC 2016 New revision: 295914 URL: https://svnweb.freebsd.org/changeset/base/295914 Log: MFV r295913: Partially apply upstream changeset 6e06b1c8 (kientzle). Limit filter recursion level to 25 (instead of infinite). This fixes a potential crash issue discovered by Alexander Cherepanov. PR: 207362 Reported by: Robert Clausecker Obtained from: libarchive github project Changes: _U head/contrib/libarchive/ _U head/contrib/libarchive/libarchive/ head/contrib/libarchive/libarchive/archive_read.c A commit references this bug: Author: delphij Date: Tue Feb 23 08:12:39 UTC 2016 New revision: 295915 URL: https://svnweb.freebsd.org/changeset/base/295915 Log: Instant-MFC r295914: MFV r295913: Partially apply upstream changeset 6e06b1c8 (kientzle). Limit filter recursion level to 25 (instead of infinite). This fixes a potential crash issue discovered by Alexander Cherepanov. PR: 207362 Reported by: Robert Clausecker Obtained from: libarchive github project Approved by: so Changes: _U stable/9/contrib/libarchive/ _U stable/9/contrib/libarchive/libarchive/ stable/9/contrib/libarchive/libarchive/archive_read.c A commit references this bug: Author: delphij Date: Wed Feb 24 05:40:04 UTC 2016 New revision: 295961 URL: https://svnweb.freebsd.org/changeset/base/295961 Log: MFC r295914: MFV r295913: Partially apply upstream changeset 6e06b1c8 (kientzle). Limit filter recursion level to 25 (instead of infinite). This fixes a potential crash issue discovered by Alexander Cherepanov. PR: 207362 Reported by: Robert Clausecker Obtained from: libarchive github project Approved by: re (marius) Changes: _U stable/10/ stable/10/contrib/libarchive/libarchive/archive_read.c Already committed by delphij. MARKED AS SPAM MARKED AS SPAM |
Created attachment 167205 [details] gzip quine, unpacks to itself The FreeBSD tar(1) program uses a heuristic to check if an archive file is compressed. If it is, it calls into an appropriate library to receive a decompressed stream. Then it applies the heuristic again to catch the case of an archive that has been compressed multiple times. There is no limit to the number of recursive decompressions. Using a crafted gzip file (the attached file is a quine that unpacks to itself), one can get tar(1) to invoke an infinite chain of gzip compressors until all the memory on the machine running tar(1) has been exhausted or another resource limit kicks in. I see this behaviour as a bug and security problem. It can be used to perform denial-of-service attacks against machines that run FreeBSD and use tar(1) to list the contents of untrusted archives.