New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] unzip: CVE-2019-13232 (release-19.03) #64910
Conversation
(cherry picked from commit 2868c75)
Please perform the cherry pick after the original changeset is accepted. The motivation is that we/I typically pull requests instead of merge them. |
@FRidh, ack I will, thank you. |
Again, would this be better aimed at |
I wouldn't hurry with backporting this, as I see it causes multiple regressions. |
the cherry-pick -x reference is not correct |
I agree, setting up as [WIP] until we fix the regression. At the moment I know of only one, |
Here's the other I've seen: 0238946#commitcomment-34378254 |
Thanks to @vcunat the The question is, how we want to approach this in release-19.03 and if this CVE severity outweighs updating |
For unzipping sources we could have an unpatched variant that's explicitly chosen in the problematic cases. EDIT: but in general this CVE doesn't seem serious to me. |
That would work for packages with |
After considering the severity of this CVE along with the fixes needed to 19.03 to fix the regressions I think it's not worth backporting this CVE. |
I see many lua's
|
This detects an invalid zip file that has at least one entry that overlaps with another entry or with the central directory to the end of the file. A Fifield zip bomb uses overlapped local entries to vastly increase the potential inflation ratio. Such an invalid zip file is rejected. See https://www.bamsoftware.com/hacks/zipbomb/ for David Fifield's analysis, construction, and examples of such zip bombs. The detection maintains a list of covered spans of the zip files so far, where the central directory to the end of the file and any bytes preceding the first entry at zip file offset zero are considered covered initially. Then as each entry is decompressed or tested, it is considered covered. When a new entry is about to be processed, its initial offset is checked to see if it is contained by a covered span. If so, the zip file is rejected as invalid. This commit depends on a preceding commit: "Fix bug in undefer_input() that misplaced the input state."
@vcnuat Can you provide a link to some of these "rock" files that are failing? |
@madler: I'm sorry; it seems likely that the vast majority of these are our mistake of not reading your commit message properly. This particular one does succeed when using both of the patches. |
Does "vast majority" mean that there are still some that indicate overlapped entries that you think is incorrect? |
I'm not aware of any at this moment. When I see some, I'll mention you. I expect we will soon try a full rebuild with a complete set of patches. |
Motivation for this change
Fixes #64663.
(cherry picked from commit 2868c75)
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)