Tommi Prami 131 Posted March 31, 2022 https://nakedsecurity.sophos.com/2022/03/29/zlib-data-compressor-fixes-17-year-old-security-bug-patch-errr-now/ -Tee- 1 Share this post Link to post
Attila Kovacs 631 Posted March 31, 2022 Was the sechole bad? Can you/someone generate the objs? Share this post Link to post
Anders Melander 1815 Posted March 31, 2022 As far as I've been able to evaluate this bug isn't much of a problem for Delphi desktop applications. Server applications could have a problem if they do compression of user supplied data (the bug only exists in the zlib compressor) but since it's only a buffer overrun (as far as I can tell) it's not that bad. 1 Share this post Link to post
Anders Melander 1815 Posted March 31, 2022 From: https://www.openwall.com/lists/oss-security/2022/03/28/1 via https://github.com/madler/zlib/issues/605#issuecomment-1084218467 Quote Note, this is very sensitive to the specific parameters chosen, especially the memLevel of 1 which I expect is not very commonly used. With memLevel=1, zlib only uses very short blocks, so it's possible for the block header to bring the average match cost above the 24 bits needed to hit the bug. I'm not seeing a way for the bug to be reachable with much higher memLevels, notably the default memLevel of 8; as far as I can tell, the average match cost can't be much over 23 bits in that case. The following are the only (two) calls to DeflateInit2 in the Delphi source (System.ZLib.pas): procedure ZCompress2(const inBuffer: TBytes; out outBuffer: TBytes); ... begin ... ZCompressCheck(DeflateInit2(zstream, 1, 8, -15, 9, 0)); ... constructor TZCompressionStream.Create(dest: TStream; compressionLevel: TZCompressionLevel; windowBits: Integer); begin ... ZCompressCheck(DeflateInit2(FZStream, ZLevels[compressionLevel], Z_DEFLATED, windowBits, 8, Z_DEFAULT_STRATEGY)); end; Note that one uses MemLevel=9 and the other MemLevel=8. None uses the Z_FIXED method the original bug was about. Share this post Link to post