Mitigating the iconv Vulnerability for PHP (CVE-2024-2961)
Tags: linux, php, security
Published: 2024-04-23 02:33:44

> This post originally appeared on my blog, [here](https://garrettmills.dev/blog/2024/04/22/Mitigating-the-iconv-Vulnerability-for-PHP-CVE-2024-2961/).

Recently, [CVE-2024-2961](https://www.openwall.com/lists/oss-security/2024/04/18/4) 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](https://www.offensivecon.org/speakers/2024/charles-fol.html)... 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

```shell
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:

```text
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:

```text
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`:

```shell
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:

```shell
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`:

```shell
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:

```shell
rm gconv-modules.cache
```

> You can regenerate that cache file using [`iconvconfig(8)`](https://www.man7.org/linux/man-pages/man8/iconvconfig.8.html).

Then re-check for the vulnerable encodings:

```shell
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:

```dockerfile
# 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.