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

[vielmetti]

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.

[vielmetti]

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

[vielmetti]

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

[ynezz]

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

[vielmetti]

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

[vielmetti]

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.

[vielmetti]

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".

[briangreenery]

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.

[vielmetti]

@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 .

[vielmetti]

@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.

[vielmetti]

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.

[vielmetti]

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.

[madler]

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.

[rurban]

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) {

[madler]

I don't understand your comment rurban.

[ncopa]

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.

When cherry-picking it to Alpine Linux I saw that there was a second commit (4346a16) that was done the same day as the commit that fixes the CVE. It happens that security fixes introduces regressions or are incomplete so I often look at commits that happens directly before and after security fixes. I also thought that it looked like 4346a16 commit could have security implication, but I have no idea if its does. I included it just in case, and because the change was done at the same time as the security fix.

[ebiggers]

Note, this is also reproducible with Z_DEFAULT_STRATEGY when memLevel=1 and windowBits=15.

[madler]

@ebiggers Can you provide an example?

[madler]

zlib 1.2.12 is now live on the master branch here, which includes the remedy from 2018.

[vielmetti]

Closed by 21767c6 , thanks @madler .

[taviso]

@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.

[Adenilson]

For Chromium (and AOSP since it uses Chromium's zlib starting with Android R), we actively backported the fix from 'develop' all the way back in 2018:
https://chromium.googlesource.com/chromium/src/+/777b3763b4f45e4e10f6ff3c6cd46c6e086dc243

Plus, we have fuzzers covering Z_FIXED:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/zlib/contrib/tests/fuzzers/deflate_fuzzer.cc;l=30

[Adenilson]

A unit test stressing the bug can be found at:
https://chromium-review.googlesource.com/c/chromium/src/+/3550971

[Hanmac]

@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?

[vittring]

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

[ljavorsk]

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?

[ebiggers]

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.

[ebiggers]

@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.

[ljavorsk]

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?

[vielmetti]

@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.