An argument for a better defined file format specification perhaps, but I don't think it's necessarily a good thing for everyone to use or have to use the same implementation.
As someone who works on specs that are shared across different organizations' implementations, you can write all the specs you want but no conformance tests = no conformance.
If everyone has the same parser the whole classes of bugs just stop being exploitable. The classic one being one parser at the edge validates somethhing and the further down the line sees another result which it expects tp be rejected during validation.
Both parsers could be buggy, but when they have different kinds of bugs, you get a zero click undetectable exploit
I don’t think it’s this simple: you can still produce observable differentials with a single parser by using different options within that parser in different places. The ZIP format itself affords ample opportunities for that.
Differentials are oracular; you only need one bit. And I’m not claiming it’s in zlib, since zlib isn’t a ZIP library. TFA here is about ZIP differentials, not differentials in DEFLATE stream parsers.
Unless, of course, the differential occurs between versions of zlib. I think the bigger problem here is that ZIP is just not a very well defined format.
An argument for a better defined file format specification perhaps, but I don't think it's necessarily a good thing for everyone to use or have to use the same implementation.
As someone who works on specs that are shared across different organizations' implementations, you can write all the specs you want but no conformance tests = no conformance.
A good point! Conformance tests seem like a great idea to me to go along with specs.
If everyone has the same parser the whole classes of bugs just stop being exploitable. The classic one being one parser at the edge validates somethhing and the further down the line sees another result which it expects tp be rejected during validation.
Both parsers could be buggy, but when they have different kinds of bugs, you get a zero click undetectable exploit
I don’t think it’s this simple: you can still produce observable differentials with a single parser by using different options within that parser in different places. The ZIP format itself affords ample opportunities for that.
The settings are at encode time. For two readers the results should be unambiguous.
There are plenty of decode-time knobs, even within a single ZIP parser. Here are just a few you could set while using libzip[1].
[1]: https://libzip.org/documentation/zip_open.html#DESCRIPTION
That’s not a lot of settings, and that’s libzib, which is not zlib.
Differentials are oracular; you only need one bit. And I’m not claiming it’s in zlib, since zlib isn’t a ZIP library. TFA here is about ZIP differentials, not differentials in DEFLATE stream parsers.
It significantly increases the attack surfaces of bugs that do exist in the parser if the same implementation is used everywhere.
Unless, of course, the differential occurs between versions of zlib. I think the bigger problem here is that ZIP is just not a very well defined format.
zlib (deflate) is just the compression type usually (not always) used in zips
zip is the container around it
zlib comes with a basic ZIP implementation (libminizip).