5 ms·
I recently created a zip validator and decoder for scanning email attachments, @ronomon/zip. It's not yet open-sourced but it has defenses against excessive co
by jorangreef 7y ago
I recently created a zip validator and decoder for scanning email attachments, @ronomon/zip.
It's not yet open-sourced but it has defenses against excessive compression ratios, mismatching local and central directory headers, ambiguous filenames, directory traversals and symlink traversals, and anything ambiguous that could exploit differences in zip implementations, e.g. some zip implementations decode from the front while others decode from the back. Most importantly, it balks at deviations from the zip format, including any kind of overlapping or sparseness, buffer bleeds etc.
At least it detected all three of the author's samples as malicious.
- rattray 7y agoNow might be a good time to open-source it, even if it doesn't "feel ready" yet. There may be developers who would install it today, as zip bombs are on their mind, and upgrade it in the near term, but would otherwise forget about zip vulns entirely as they go about their days.
- SahAssar 7y agoIf it does not "feel ready" I wouldn't want to expose it to random emails or HTTP. There are a lot worse things than zip bombs that can be used to attack and those avenues are basically open to the internet.
- jorangreef 7y agoThanks for the encouragement: https://github.com/ronomon/zip https://github.com/ronomon/zip
- hinkley 7y agoIf I recall my PKZip lore, being able to append an updated file to the end of a zip was considered a feature. That leaves a dead copy of the file earlier in the archive, but saves you having to do the floppy shuffle to update one file. But I don’t recall ever mentioning that fact to someone who already knew it. While you could probably get away with rejecting that file (who still uses that? Some sort of streaming protocol?), it was a feature at one point.
- jorangreef 7y agoYes, I made a decision to reject incrementally updated archives. It was a feature back in the day, but as you say it also leaves dead zones in the archive. For a rarely used feature, it's a dangerous feature. These "invisible" dead zones can be used for malware stuffing, or to exploit ambiguity across different zip implementations, those that parse forwards (using the local file header as the canonical header) and those that parse backwards (using the central directory header as the canonical header). For example, a malware author might put an EXE in the first version of a file, and a TXT in the second version of that same file. Those that parse forwards get the EXE. Those that parse backwards get the TXT. Of course, the spec advocates parsing backwards according to the central directory record, but implementations exist that don't do this. The goal of @ronomon/zip is to scan email attachments at the gateway and reject zip archives that might prove dangerous to more vulnerable zip software running downstream (MS Office, macOS) etc. Also, as you say, I don't think incrementally updated archives are used much. From what I could see, there were no false positives for rejecting gaps between referenced local files on a small sample of 5000 archives.
- Mazzen 7y agoI understand that you don't want to release prematurely but what I don't understand: Why don't you release your code from the first line written? I start committing to Github right from the start. Others might already want to follow your project or even contribute PRs. I'd definitely be interested. Maybe at least create the repo so we can subscribe to activities ;) Best!
- jobigoud 7y agoIt's like asking an artist to show their initial drafts and sketches that are probably looking pretty bad, at a point they don't yet know where it's going or if they will even finish the piece. Some have enough confidence and are willing to do it, others would rather only show the final piece and be free to not publish anything if they aren't happy with the result. Both stances are ok.