Description of problem: A new zip bomb is discovered, which makes unpacking a 46MB zip file expand to 4.5 PetaBytes. There is a patch in debian for unzip v6.0, but it does not apply to our v6.1c. How reproducible: Allways Steps to Reproduce: 1. unzip the zbsm.zip (it is a 42 Kb file which «only» expands to 5.5 GigaBytes, will attach it after submitting this) 2. It will unpack 250 files, consuming a total of 5461307620 bytes (some 5.5 GB)
Created attachment 11165 [details] example zip archive to show the problem
Whiteboard: (none) => MGA7TOO, MGA6TOO
A link to the Debian patch would be nice.
Created attachment 11167 [details] Debian patch, combining two commits which fixes the issue. (In reply to Jani Välimaa from comment #2) > A link to the Debian patch would be nice. Yea, I thought so too, but it is not publicly available on their patch trakcers, nor in their web-available source links. But the patch is from a «fork» created by one of the original unzip developers, who forked it for the sole purpose of fixing this bug: https://github.com/madler/unzip The debian patch (attached) combines the two commit's recuired to fix the bug in unzip v6.0.
QA Contact: (none) => securityComponent: RPM Packages => Security
Debian packages should be available through: https://packages.debian.org/search?searchon=sourcenames&keywords=unzip or: https://sources.debian.org/src/unzip/
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => shlomif
Hi all! http://pkgsubmit.mageia.org/ - unzip 6.1c-4mga for mga8 should fix this there but requires more testing. I ported the patch.
It breaks building LibreOffice: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20190807081936.tv.duvel.17138/log/libreoffice-6.3.0.4-1.mga8/build.0.20190807082011.log This source file which was used for nearly a decade now fails: unzip -t a7983f859eafb2677d7ff386a023bc40-xsltml_2.1.2.zip Archive: a7983f859eafb2677d7ff386a023bc40-xsltml_2.1.2.zip testing: README OK error: invalid zip file with overlapped components (possible zip bomb)
CC: (none) => thierry.vignaud
The "fun" part being that we can no more build unzip: Executing(%prep): /bin/sh -e /home/tv/mga/pkgs/LO/libreoffice/SOURCES/unzip/BUILDROOT/rpm-tmp.AjrKY4 + umask 022 + cd /home/tv/mga/pkgs/LO/libreoffice/SOURCES/unzip/BUILD + '[' 1 -eq 1 ']' + '[' 1 -eq 1 ']' + '[' 1 -eq 1 ']' + cd /home/tv/mga/pkgs/LO/libreoffice/SOURCES/unzip/BUILD + rm -rf unzip610c25 + /usr/bin/unzip -qq /home/tv/mga/pkgs/LO/libreoffice/SOURCES/unzip/SOURCES/unzip610c25.zip error: invalid zip file with overlapped components (possible zip bomb) error: Bad exit status from /home/tv/mga/pkgs/LO/libreoffice/SOURCES/unzip/BUILDROOT/rpm-tmp.AjrKY4 (%prep)
There is a new upstream commit (13 days ago in the forked repo) which possibly fixes this: https://github.com/madler/unzip/commit/6d351831be705cc26d897db44f878a978f4138fc.patch
Re-assigning globally due to change to no specific maintainer.
Whiteboard: MGA7TOO, MGA6TOO => MGA7TOOAssignee: shlomif => pkg-bugs
Summary: CVE-2019-13232: overlapping of files in ZIP container leads to denial of service by completely filling up the disk => unzip new security issue CVE-2019-13232
CC: (none) => nicolas.salguero
RedHat has issued an advisory for this today (April 28): https://access.redhat.com/errata/RHSA-2020:1787
this is fixed in cauldron. There is CVE-2019-13232--v5.patch using debian patch + https://github.com/madler/unzip/commit/6d351831be705cc26d897db44f878a978f4138fc.patch
Whiteboard: MGA7TOO => (none)Version: Cauldron => 7CC: (none) => mageia
in fact it is not enabled :-)
Whiteboard: (none) => MGA7TOOVersion: 7 => Cauldron
Ubuntu has issued an advisory for this on December 16: https://ubuntu.com/security/notices/USN-4672-1
Status comment: (none) => Patches available from RedHat, Debian, and Ubuntu
I adapted the 3 patches mentioned in the Red Hat bug report provided in the git repo https://github.com/madler/unzip: - 41beb477c5744bc396fa1162ee0c14218ec12213.patch - 47b3ceae397d21bf822bc2ac73052a4b1daf8e1c.patch - 6d351831be705cc26d897db44f878a978f4138fc.patch I committed them in mga7 and made a local version of unzip. However, with that version installed, it still produces a 4.5 GB set of files so I'm unsure whether the 3 patches really fix the issue. Could someone else look at that as well and advise ?
Status: NEW => ASSIGNEDCC: (none) => bruno
Thanks for looking at it. Which PoC file did you use? Link in the URL says the last one is 4.5 *peta* bytes which you wouldn't have the disk space for. As long as the regression in Comment 8 doesn't happen, we should commit the patches in Cauldron, but we do need to check that first.
(In reply to Bruno Cornec from comment #15) > However, with that version installed, it still produces a 4.5 GB set of > files so I'm unsure whether the 3 patches really fix the issue. As I read the patch set currently used it looks like the unpacking should be abborted with an error: «ERROR: invalid zip file with overlapped components (possible zip bomb)» So if it does unpack the 41k test-bomb file to 4.5 gig, then my guess is that it didn't fix the issue.
By the way, the forked repo forked the 6.00 version released in 2009. So it wouldn't fix our 6.10c25 version. I also notice that according to Repology[1] we are one of 9 distros that use the newer 6.1x versions. Every one else is using the upstream old latest official v6.0 – including Red Hat where the patches we use apparently comes from. [1] https://repology.org/project/unzip/badges The forked repo[2] has by the way tagged a release 6.00b1 (in februray 2020) that apparently has fixed this, and he responds to bug repports. So we might want to consider switching to the forked version. (Would need to use epoch thou, but if that is what it takes to fix it…) [2] https://github.com/madler/unzip
(In reply to David Walser from comment #16) > Thanks for looking at it. Which PoC file did you use? Link in the URL says > the last one is 4.5 *peta* bytes which you wouldn't have the disk space for. > > As long as the regression in Comment 8 doesn't happen, we should commit the > patches in Cauldron, but we do need to check that first. I used the file attached in this ticket, which is a sample of the size expressed. the 45 MB generates indeed a 5.5 GB set of files. So it seems that after applying the patches, of course slightly modified, the PoC still shows the issue, so something is wrong somewhere, and that can be my try to adapt the patches.
(In reply to Johnny A. Solbu from comment #18) > By the way, the forked repo forked the 6.00 version released in 2009. > So it wouldn't fix our 6.10c25 version. > [...] > The forked repo[2] has by the way tagged a release 6.00b1 (in februray 2020) > that apparently has fixed this, and he responds to bug repports. > > So we might want to consider switching to the forked version. > (Would need to use epoch thou, but if that is what it takes to fix it…) > > [2] https://github.com/madler/unzip So do you want me to push that repo as the new unzip version for both cauldron and mga7 ? Should that be discussed on the dev ML so we get some concensus around that ?
Ok, 5.5 GB is the first PoC file (see the URL field), so this is still unfixed. It would be worth asking about switching upstreams on the dev ml. Probably should test a local build with the other one to make sure it does indeed fix the issue.
what means "switch upstream" ?
Nicolas, see Comment 18.
Whiteboard: MGA7TOO => MGA7TOO, MGA8TOO
i switched back to version 6.0 + CVE patches. I pushed it in updates_testing. Can you test the zipbomb part ?
I only tested the zbsm.zip, but with Mageia 7's unzip I got 250 files (21M each) with 5.1G of disk usage. Using the Mageia 8 updates_testing 6.0 unzip results in this: Archive: ../zbsm.zip inflating: 0 error: invalid zip file with overlapped components (possible zip bomb) And the one file is 21M. So yes, it fixes the issue.
The change back to 6.0 reverts the fixes for these: https://bugs.mageia.org/show_bug.cgi?id=22571 (except for CVE-2018-1000035 which is fixed in what you have already). LOCAL_UNZIP needs to be set: http://svnweb.mageia.org/packages/cauldron/unzip/current/SPECS/unzip.spec?r1=1319952&r2=1319951&pathrev=1319952 and the LZMA code needs to be disabled.
Actually it sounds like the LZMA code was only in 6.1c, so it should be good now.
Fixed in cauldron
Whiteboard: MGA7TOO, MGA8TOO => (none)Version: Cauldron => 7
Suggested advisory: ======================== The updated package fixes a security vulnerability: Info-ZIP UnZip 6.0 mishandles the overlapping of files inside a ZIP container, leading to denial of service (resource consumption), aka a "better zip bomb" issue. (CVE-2019-13232) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13232 https://access.redhat.com/errata/RHSA-2020:1787 https://ubuntu.com/security/notices/USN-4672-1 ======================== Updated package in core/updates_testing: ======================== unzip-6.0-1.mga7 from SRPM: unzip-6.0-1.mga7.src.rpm
Assignee: pkg-bugs => qa-bugsSource RPM: unzip-6.1c-3.mga7 => unzip-6.1c-3.1.mga7.srcCVE: (none) => CVE-2019-13232Status comment: Patches available from RedHat, Debian, and Ubuntu => (none)
Installed and tested without issues. Tested using the zbsm.zip. The zip bomb seems to be disarmed. ;-) System: Mageia 7, x86_64, Intel CPU. $ uname -a Linux marte 5.10.6-desktop-1.mga7 #1 SMP Sat Jan 9 20:09:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q unzip unzip-6.0-1.mga7 $ unzip zbsm.zip Archive: zbsm.zip inflating: 0 error: invalid zip file with overlapped components (possible zip bomb)
CC: (none) => mageia
Looks like enough to me. Validating. Advisory in Comment 29.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA7-64-OKCC: (none) => andrewsfarm, sysadmin-bugs
Same test. Advisory pushed to SVN.
CC: (none) => ouaurelienKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0033.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED