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 below 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.
Top comments (0)