Mitigating the iconv Vulnerability for PHP (CVE-2024–2961)

This post originally appeared on my blog, here.

Recently, CVE-2024–2961 was released which identifies a buffer overflow vulnerability in GNU libc versions 2.39 and older when converting charsets to certain Chinese Extended encodings.

This vulnerability affects PHP when iconv is used to translate request encodings to/from the affected charsets and has the potential to be wide-ranging (e.g. the latest wordpress:apache image has iconv with the vulnerable charsets enabled).

Obviously, the best mitigation is to update to a patched version of glibc. However, if you are unable to (or it's not available on your OS yet), you can mitigate this issue by disabling the affected charsets in gconv.

I had a really hard time finding information on how to check for and mitigate this issue at the OS-level (possibly because the researcher who discovered the CVE is presently teasing details about the PHP exploit for his talk at a conference… 3 weeks after the CVE was announced. 🙄)

I’ve collected my notes here, in case they might be useful for someone else.

Check if your OS is vulnerable

ldd --version

The first line of the linker version info should include the version of glibc (either as GLIBC or GNU libc).

Example from Debian 12:

ldd (Debian GLIBC 2.36-9+deb12u4) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Example from Rocky Linux 9:

ldd (GNU libc) 2.34
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

You can also use your package manager to check (for example, rpm -q glibc).

If you are using glibc 2.39 or older, then the ISO-2022-CN-EXT encodings are vulnerable for your system's iconv and gconv.

Check for bad encodings

Check if the vulnerable encodings are enabled in iconv:

iconv -l | grep -E 'CN-?EXT'

If they are, you will see an output like:

ISO-2022-CN-EXT//
ISO2022CNEXT//

Disable bad encodings

We can modify the gconv-modules configuration to disable the affected charsets:

cd /usr/lib/x86_64-linux-gnu/gconv

This might be in slightly different locations for exotic systems. Try find / -name gconv-modules.

Disable the offending encodings in the gconv-modules config file. This will either be in gconv-modules directly, or in something like gconv-modules.d/gconv-modules-extra.conf:

cd gconv-modules.d
cat gconv-modules-extra.conf | grep -v -E 'CN-?EXT' > gconv-modules-extra-patched.conf
mv gconv-modules-extra-patched.conf gconv-modules-extra.conf
cd ..

Remove the cache file if present:

rm gconv-modules.cache

You can regenerate that cache file using iconvconfig(8).

Then re-check for the vulnerable encodings:

iconv -l | grep -E 'CN-?EXT'

There should be no output from this command.

Docker

For those using Docker images, here’s a convenient Dockerfile blurb:

# Disable vulnerable iconv encodings (CVE-2024-2961)
RUN cd /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.d \
    && cat gconv-modules-extra.conf | grep -v -E 'CN-?EXT' > gconv-modules-extra-patched.conf \
    && mv gconv-modules-extra-patched.conf gconv-modules-extra.conf \
    && rm -f ../gconv-modules.cache \
    && iconvconfig \
    && iconv -l | grep -E 'CN-?EXT' && exit 1 || true

That last line contains one of my favorite Dockerfile tricks (check-something && exit 1 || true) -- your Docker build will fail if the vulnerable charsets are enabled.

A previous version of this post kept gconv-modules-extra-patched.conf. Thanks to Anonymous for pointing out that a subsequent RPM update could re-introduce the file.

A previous version of this post indicated that `glibc` versions < 2.39 were vulnerable. Thanks to Geert for noting that 2.39 is also vulnerable.