Re: unzip CVE-2019-13232
Hi Markus,
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 [1] 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 [2]. 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:
https://salsa.debian.org/security-tracker-team/security-tracker/commit/0891eec1447b20c9f45d18754f733df2081bbda3
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? :)
https://bugs.debian.org/932318
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.
Regards,
Salvatore
Reply to: