CVE-2018-25032 (zlib memory corruption on deflate)

@madler

CVE-2018-25032 tracks a bug in zlib 1.2.11 which allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.

There is a fix from @madler at 5c44459

@taviso reports at https://www.openwall.com/lists/oss-security/2022/03/24/1 that this patch never made it into a release, and at the time of writing no distros had picked it up as a fix.

Fix a bug that can crash deflate on some input when using Z_FIXED.

@twz123

PR to fix in nixpkgs from @twz123 NixOS/nixpkgs#165642

@ncopa

PR to fix in Alpine aports from @ncopa https://git.alpinelinux.org/aports/commit/?id=361df5902aa1e81594b17f06a13e10527dfb8aed and alpinelinux/aports@361df59

Fixed in OpenWrt down to 19.07 release with openwrt/openwrt@b3aa290

Fixed in Debian, the relevant bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008265 and the version with the fix is zlib/1:1.2.11.dfsg-4

Ubuntu has tracked this as https://ubuntu.com/security/CVE-2018-25032 and has a proposed patch which will bring the version to 1:1.2.11.dfsg-2ubuntu9, details are up to date at https://launchpad.net/ubuntu/+source/zlib . Ubuntu notes that "rsync" is also affected and is fixed in 3.1.3-6.

Fedora and Red Hat are tracking this bug at https://bugzilla.redhat.com/show_bug.cgi?id=2067945 and there is no "fixed in" version as of this writing. It's also marked as affecting the packages "mingw-zlib" and "rsync".

Do you know if the full fix requires both of these commits?

5c44459
4346a16

I only see the first commit referenced as related to the CVE, but the linked NixOS and Alpine issues are applying both commits. I'm not sure how they knew the second commit should also be applied.

@briangreenery

@briangreenery It looks like this Ubuntu patch at https://launchpad.net/ubuntu/+source/zlib/1:1.2.11.dfsg-2ubuntu9 also picks up the deflatePrime() validation check you reference at 4346a16 .

Assure that the number of bits for deflatePrime() is valid.

@taviso

@taviso posts a reproducer at https://www.openwall.com/lists/oss-security/2022/03/26/1 with a sample input file that triggers the bug when run against a minimal compressor that uses zlib.

@bluhm

In https://twitter.com/OpenBSD_src/status/1507325285665968130 there is a reference to a (forthcoming) errata for OpenBSD with the name "errata/7.0/018_zlib.patch.sig".

From the looks of it this hasn't been published just yet, but when it does I expect it to be at https://ftp.openbsd.org/pub/OpenBSD/patches/7.0/common/

The reference acknowledges mbuhl and millert of the OpenBSD project.

From the looks of it, @bluhm is also doing work for OpenBSD on zlib, see e.g.
openbsd/src@b1b1dcf
which references 38e8ce3
fixing the CLEAR_HASH macro.

@nmoinvaz

In zlib-ng/zlib-ng#1208 @nmoinvaz adds a unit test for CVE-2018-25032 using test/CVE-2018-25032/test.txt which is a file beginning with AAABAACAA that was contributed by @taviso .

zlib-ng passes the unit test for that file, whereas zlib (master) does not.

So much excitement! I will release the develop branch to master. Note that this bug is only when Z_FIXED is used, which it never is in production code. The only reason it's there is to facilitate testing of the decompression of fixed blocks.

not really, because of this condition:

https://github.com/madler/zlib/blob/master/trees.c#L976

} else if (s->strategy == Z_FIXED || static_lenb == opt_lenb) {

chore: bump zlib to 1.2.12

update zlib dependency from 1.2.11 -> 1.2.12

Fix broken zlib dependency, update it from 1.2.11 to 1.2.12 (#9764)

@madler

@madler Eric posted a reproducer that does work with Z_DEFAULT_STRATEGY to oss-security. The file is here: https://www.openwall.com/lists/oss-security/2022/03/28/1

IMHO, that makes this bug far more critical.

does the new 1.2.12 release fixes this problem too, or will there be a followup issue?

I just saw this CVE using Snyk to scan a container image. Glad the bug has a patch! Thanks for the fix!

Could anyone please give me some guidance regarding the reproducer?
I've managed to compile the deflate.c file and use its binary with the reproducer .txt file, but no error occurred in my case.

Then I saw, that I should you the zpipe utility, but that's where the problem arrives.
I'm fairly new to the zlib and I'm not really sure how to use the zpipe and what do you refer to as "garbage" from its output.

I would be so grateful for any kind of help with this.

How I've used the zpipe:
wget https://www.zlib.net/zpipe.c -> Downloaded it from this source
cc -o zpipe zpipe.c -lz -> Found that it should be compiled like this
./zpipe < CVE-2018-25032.txt > decompres -> Used it according to the manual
How do I determine if the decompres file is garbage?

Could anyone please give me some guidance regarding the reproducer?

I've` managed to compile the deflate.c file and use its binary with the reproducer .txt file, but no error occurred in my case.

It is an out-of-bounds memory read, which is undefined behavior, so a crash is not guaranteed. You can compile both zlib and the program using gcc's -fsanitize=address option to get AddressSanitizer to report the out-of-bounds read.

I'm fairly new to the zlib and I'm not really sure how to use the zpipe and what do you refer to as "garbage" from its output.

The point is that if CVE-2018-25032.txt is deflated and then inflated, it doesn't match the original file. There are many ways to test this. The deflate.c programs that Tavis and I posted only have the deflate(), as they were only intended to reproduce the out-of-bounds access. So you would need to add an inflate() if you wanted to verify the issue with the round trip.

@madler

@madler Eric posted a reproducer that does work with Z_DEFAULT_STRATEGY to oss-security. The file is here: https://www.openwall.com/lists/oss-security/2022/03/28/1
IMHO, that makes this bug far more critical.

does the new 1.2.12 release fixes this problem too, or will there be a followup issue?

This was essentially the same problem, so it was fixed by the same commit and thus is fixed in 1.2.12.

The point is that if CVE-2018-25032.txt is deflated and then inflated, it doesn't match the original file. There are many ways to test this. The deflate.c programs that Tavis and I posted only have the deflate(), as they were only intended to reproduce the out-of-bounds access. So you would need to add an inflate() if you wanted to verify the issue with the round trip.

And did someone (if you know of anything that could be used in this test) create the inflate() already so I don't invent the wheel again?

@ljavorsk

@ljavorsk this commit in @zlib-ng zlib-ng/zlib-ng#1208 from @nmoinvaz adds a unit test and a "minideflate.c" and an "inflate.c" which I think is what you are looking for. No need to reinvent this particular wheel.

Fix broken zlib dependency, update it from 1.2.11 to 1.2.12 (#9764)

Fix broken zlib dependency, update it from 1.2.11 to 1.2.12 (meta#9764)

Fix broken zlib dependency, update it from 1.2.11 to 1.2.12 (#9764)

Fix broken zlib dependency, update it from 1.2.11 to 1.2.12 (meta#9764)

Navigation Menu

Repository navigation

CVE-2018-25032 (zlib memory corruption on deflate) #605

12 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

CVE-2018-25032 (zlib memory corruption on deflate) #605

Description

Activity

vielmetti commented on Mar 26, 2022

vielmetti commented on Mar 26, 2022

ynezz commented on Mar 26, 2022

vielmetti commented on Mar 26, 2022

vielmetti commented on Mar 26, 2022

vielmetti commented on Mar 26, 2022

briangreenery commented on Mar 26, 2022

vielmetti commented on Mar 26, 2022

vielmetti commented on Mar 26, 2022

vielmetti commented on Mar 27, 2022

vielmetti commented on Mar 27, 2022

madler commented on Mar 27, 2022

rurban commented on Mar 27, 2022

12 remaining items

Hanmac commented on Mar 31, 2022

vittring commented on Apr 1, 2022

ljavorsk commented on Apr 8, 2022

ebiggers commented on Apr 8, 2022

ebiggers commented on Apr 8, 2022

ljavorsk commented on Apr 11, 2022

vielmetti commented on Apr 11, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions