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.
Attachment:
signature.asc
Description: OpenPGP digital signature