[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: unzip CVE-2019-13232

Hi Salvatore,

Am 03.08.19 um 09:12 schrieb Salvatore Bonaccorso:
> 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.

Ok, but remember that unpacking email attachments is quite common and
concealed malicious files are often attached or linked to in various
spam emails. At best this could also simply be used as a hoax because it
is tempting to fool people by letting them unpack files with an output
size in the hundreds of TB region.

> The above btw, corresponds as well to upstream point of view:
> https://www.bamsoftware.com/hacks/zipbomb/ -> UnZip 6.0

I believe David Fifield is not the upstream developer of unzip but
rather the discoverer of said bug. Even if the ability of creating
overlapping files in zip containers is within the specification, you
should take into consideration how easy it is to do something harmful
with it. Since unzip is omnipresent in Debian and the difficulty to do
mischief is low, I would have come to a different conclusion. Marking
CVE as unimportant should really only be used for issues that have no
real-life impact at all because we don't ship the binaries or the impact
is dependent on highly uncommon variables. This is not true for

> 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.

Right, but the mere possibility of regressions should not deter us from
fixing CVE. You can't foresee everything hence you have sometimes to
perfect the patch in step two or three. For CVE-2019-13232 the problems
with parsing some JAR files were actually no unzip bug and the problem
with Firefox's omni.ja is also a corner case since this file is also not
compliant with the zip standard.

>> 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.

Ok, great! I hope we get an update for Stretch too. In 9/10 cases a CVE
marked as unimportant would have evoked no maintainer reaction hence I
would use unimportant really sparingly and only for CVE that exist but
cannot be misused.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: