sev:CRIT BoF in zlib.
zlib versions up to and including 1.3.1.2 contain a global buffer overflow in the untgz utility. The TGZfname() function copies an attacker-supplied archive name from argv[] into a fixed-size 1024-byte static global buffer using an unbounded strcpy() call without length validation. Supplying an archive name longer than 1024 bytes results in an out-of-bounds write that can lead to memory corruption, denial of service, and potentially code execution depending on compiler, build flags, architecture, and memory layout. The overflow occurs prior to any archive parsing or validation.
@cR0w brb I'll just update the _gazillion_ embedded zlib libraries in ... EVERYTHING
@troed Yeah, I tried to not overhype it because IDK what all versions are where, but it's all over the place. It could be an interesting one to watch for sure.
Yeah but don't assume untgz is in there. It's old, the issue is in having to search through every single embedded system to see if _they_ include it ...
Ah. This issue was reported already three years ago and Adler pointed out that anything in contrib/ is not considered part of zlib.
Someone would have needed to clone the repo and go out of their way to also compile untgz and include somewhere. Still something that needs checking I guess, but it's not likely to exist in _many_ places.
"ioapi.c and untgz.c are in the contrib directory, and so are not part of zlib. You can contact the authors of those codes if you like, but in any case they are not vulnerabilities in zlib." - Mark Adler
@buherator @maaneeack @troed Dammit. Aren't there multiple people from VulnCheck on fedi we could check with for more details? They're the CNA.
@buherator @maaneeack @troed Yeah. Between the slop and the state of the US these days and the reliance the rest of the world had on the US not fucking it all up, the whole vuln tracking situation sucks.