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 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
rm 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 \
 && rm -f gconv-modules-extra.conf ../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.