Add cve post
This commit is contained in:
parent
56da99740c
commit
402ab60e0e
@ -801,7 +801,7 @@ section#auth h3 {
|
|||||||
}
|
}
|
||||||
|
|
||||||
.post-title {
|
.post-title {
|
||||||
font-size: 48pt;
|
font-size: 36pt;
|
||||||
line-height: 1.5em;
|
line-height: 1.5em;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -0,0 +1,118 @@
|
|||||||
|
---
|
||||||
|
title: "Mitigating the iconv Vulnerability for PHP (CVE-2024-2961)"
|
||||||
|
slug: Mitigating-the-iconv-Vulnerability-for-PHP-CVE-2024-2961
|
||||||
|
date: 2024-04-22 20:54:06
|
||||||
|
tags:
|
||||||
|
- devops
|
||||||
|
- linux
|
||||||
|
- webdev
|
||||||
|
- hosting
|
||||||
|
---
|
||||||
|
|
||||||
|
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 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
|
||||||
|
rm 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 \
|
||||||
|
&& 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.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user