Re: unzip CVE-2019-13232
On Sat, Aug 03, 2019 at 09:12:32AM +0200, Salvatore Bonaccorso wrote:
> On Fri, Aug 02, 2019 at 06:48:05PM +0200, Markus Koschany wrote:
> > Hello Salvatore,
> > my last email regarding unzip, CVE-2019-13232, apparently remained
> > unanswered  but I feel it needs a clarification hence I am resending it.
> > I don't understand why CVE-2019-13232 was marked as
> > unimportant. According to the security tracker documentation the
> > definition for unimportant is . The reason for marking it as
> > unimportant is currently
> > "No security impact, crash in CLI tool, any server implementing
> > automatic extraction needs to apply resource limits anyway"
> > First of all there is no crash in unzip, unpacking a specially crafted
> > zip file may lead to a denial-of-service by consuming all available disk
> > space which in turn my stop certain services from working correctly.
> > In my opinion the assumption that "any server implementing automatic
> > extraction needs to apply resource limits anyway" is like assuming that
> > all server operators always implement adequate security protections for
> > all scenarios that may arise from running the services. We all know this
> > is not true in real life. Also it is perfectly possible that someone
> > sends out spam emails with a (concealed) zip bomb attached or a link
> > pointing to it which may be opened by an unsuspecting user. Non
> > tech-savvy people quickly run into troubles when they unpack such a file
> > and don't realize that their entire hard disk will fill-up in minutes.
> > If at all no-dsa would be more appropriate than unimportant in my opinion.
> The classification was done here:
> I though agree with Moritz's classification on this. Should users
> randomly unzip untrusted zip files? A better example: take a virus
> scanning engine, which extracts untrusted zip files. If this engine
> does not pose resource limits they will be out of luck very soon.
> There are different view on the issue it and I could agree that the
> classification is borderline between unimportant and no-dsa.
> The above btw, corresponds as well to upstream point of view:
> https://www.bamsoftware.com/hacks/zipbomb/ -> UnZip 6.0
> > UnZip 6.0
> > Mark Adler wrote a patch for UnZip to detect this class of zip bomb.
> > 2019-07-05: I noticed that CVE-2019-13232 was assigned for UnZip.
> > Personally, I would dispute that UnZip's (or any zip parser's)
> > ability to process a zip bomb of the kind discussed here necessarily
> > represents a security vulnerability, or even a bug. It's a natural
> > implementation and does not violate the specification in any way
> > that I can tell. The type discussed in this article is only one type
> > of zip bomb, and there are many ways in which zip parsing can go
> > wrong that are not bombs. If you want to defend against resource
> > exhaustion attacks, you should not try to enumerate, detect, and
> > block every individual known attack; rather you should impose
> > external limits on time and other resources so that the parser
> > cannot misbehave too much, no matter what kind of attack it faces.
> > There is nothing wrong with attempting to detect and reject certain
> > constructions as a first-pass optimization, but you can't stop
> > there. If you do not eventually isolate and limit operations on
> > untrusted data, your system is likely still vulnerable. Consider an
> > analogy with cross-site scripting in HTML: the right defense is not
> > to try and filter out bytes that may be interpreted as code, it's to
> > escape everything properly.
> > Mark Adler's patch made its way into Debian in bug #931433. There
> > were some unanticipated consequences: problems parsing certain Java
> > JARs (bug #931895) and problems with the mutant zip format of
> > Firefox's omni.ja file (bug #932404). SUSE decided not to do
> > anything about CVE-2019-13232. I think both Debian's and SUSE's
> > choices are defensible.
> Take into acount as well regressions in any of such software (look for
> instance at a very similar stance of a regression for bzip2 which did
> affect both the unstable upload and as well the jessie LTS upload).
> They are very "fragile" and thus needs very extra care.
> > It is quite simple to create such zip files. One can also just download
> > a 10 MB example file with an output size of 281 TB from the original
> > advisory page. Given that unzip is basically installed on every Debian
> > system and it is also the backend for popular front-ends like xarchiver,
> > I consider it to be likely that at least some users will run into issues
> > at some point. Buster will be supported for another five years and a fix
> > is available. Why don't we just fix it?
> Who said it is not going to be fixed? :)
> And I trust the maintainer Santiago that he properly will evaluate if
> an update in stretch makes similar sense or not after confidence
> nothing more gets broken.
When an early fix is more likely to introduce regressions than protect
users from real-world attacks, don't we mark it as 'postponed'?