Hi, 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 [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.
When an early fix is more likely to introduce regressions than protect users from real-world attacks, don't we mark it as 'postponed'? Cheers! Sylvain
