Re: unzip CVE-2019-13232
On 03/08/2019 14:05, Markus Koschany wrote: > Am 03.08.19 um 10:55 schrieb Sylvain Beucler: > [...] >> When an early fix is more likely to introduce regressions than protect >> users from real-world attacks, don't we mark it as 'postponed'? > We only postpone a fix if there is a minor issue and it is not worth > fixing via a standalone update. Every fix has in theory the potential to > introduce a regression because we change something. The answer can't be > to stop fixing bugs but to evaluate the possible impact of a change and > if necessary correct the patch in another step. If the risk of a > regression outweighs the benefit of a fix we usually mark the CVE as > "ignored", e.g. when upstream introduces a new security option that > requires a lot of code refactoring but only improves the security for > non-default setups in rather uncommon scenarios. That was more addressed at security-team@, I was just going your way to say that marking zip-bomb 'unimportant' just because it was likely to introduce important regressions conveyed the wrong message. - Sylvain
Re: unzip CVE-2019-13232
Am 03.08.19 um 10:55 schrieb Sylvain Beucler: [...] > When an early fix is more likely to introduce regressions than protect > users from real-world attacks, don't we mark it as 'postponed'? We only postpone a fix if there is a minor issue and it is not worth fixing via a standalone update. Every fix has in theory the potential to introduce a regression because we change something. The answer can't be to stop fixing bugs but to evaluate the possible impact of a change and if necessary correct the patch in another step. If the risk of a regression outweighs the benefit of a fix we usually mark the CVE as "ignored", e.g. when upstream introduces a new security option that requires a lot of code refactoring but only improves the security for non-default setups in rather uncommon scenarios. Regards, Markus signature.asc Description: OpenPGP digital signature
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 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 signature.asc Description: OpenPGP digital signature
Re: unzip CVE-2019-13232
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
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? W
unzip CVE-2019-13232
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. 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? Regards, Markus [1] https://lists.debian.org/debian-lts/2019/07/msg00060.html [2] unimportant: This problem does not affect the Debian binary package, e.g., a vulnerable source file, which is not built, a vulnerable file in doc/foo/examples/, PHP Safe mode bugs, path disclosure (doesn't matter on Debian). All "non-issues in practice" fall also into this category, like issues only "exploitable" if the code in question is setuid root, exploits which only work if someone already has administrative privileges or similar. This severity is also used for vulnerabilities in packages which are not covered by security support. signature.asc Description: OpenPGP digital signature
