Zlib Critical Vulnerability | Hacker News Reader

Zlib Critical Vulnerability

nvd.nist.gov

42 pointszvr13 comments

https://unzip-ada.sourceforge.io/ just sayin'.

I really feel for developers of projects like that. It presumably took a lot of work, was done a long time ago and been maintained since, and solves a lot of potential problems. But I also haven't heard of it before your post.

ada is an absolute nightmare

Ah the usual stuff, apparently zlib isn't using all those techniques and skills to write safe C code with bounds checking, as we keep being told for the last 40 years.

These appear to be the relevant changes:

2022-07-30: https://github.com/madler/zlib/commit/eff308af425b67093bab25...

2022-08-08: https://github.com/madler/zlib/commit/1eb7682f845ac9e9bf9ae3...

The second commit definitely fixed a null pointer dereference, I am not sure if the CVE is referencing something else that was fixed by the first commit.

Prior to 1.2.13 released a few days ago, neither of these commits was contained in a zlib release. The CVE exists in the state of the code prior to that first commit, and is fairly obvious when you read the explanation in the commit message. The first commit fixed the CVE but introduced a silly null pointer deference, which was quickly fixed by the second commit and never appeared in a release.

Studying the code it's easy to convince yourself that the CVE description is correct and client code that does not use inflateGetHeader() is entirely immune to the CVE. Searching GitHub suggests that use of this function is uncommon, and certainly it's not used by any of the client code that I checked for potential vulnerability to this CVE. So all the client code that I checked was unaffected by this CVE.

Hence IMHO this particular CVE is not really a big deal, because very little client software uses the somewhat obscure inflateGetHeader() API function. I suspect this is why the zlib maintainers didn't seem to be in a particular hurry to get this release out, after the CVE was made public in at least August or early September and they had already fixed it in early August. (Me, I became aware of it in early September, so the vulnerability was publicly disclosed at least by then.)

The fix in zlib 1.2.13 only appeared two days ago. I am not sure how much earlier the vulnerability was publicly disclosed.

Given the extent of use of zlib, this will result in a large number of updates of various pieces of software in many devices.

needs (Aug) btw.

Does this affect zlib-ng also?

Once I've looked into zlib code a few years ago, I abandoned it. It's a mess, only comparable to openssl, sqlite and bash.

Zlib-ng doesn't contain the same code, but it appears that their equivalent inflate() when used with their inflateGetHeader() implementation was affected by a similar problem: https://github.com/zlib-ng/zlib-ng/pull/1328

Also similarly, most client code will be unaffected because `state->head` will be NULL, because they (most client code) won't have used inflateGetHeader() at all.

> It's a mess, only comparable to openssl, sqlite and bash.

Why do you consider sqlite abandoned or a mess?

because is almost impossible to fix, harden or make secure. it's not just the broken overall architecture, which eg enables write on read, also it's internal code. eg the various attempts to get FTS. it's worse than openssl, which gets all the FLAC

> because is almost impossible to fix, harden or make secure.

I'd like some more context on this. Especially since it is used in many security-critical contexts currently.

https://github.com/rurban/hardsqlite

I gave up on it

Reply on news.ycombinator.com