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 CVE-2019-13232. [...] > 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. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature