46 lines
5.8 KiB
Markdown
46 lines
5.8 KiB
Markdown
---
|
|
title: "CVE-2021-4034"
|
|
date: "2022-01-27"
|
|
---
|
|
|
|
A few days ago, Qualys [dropped CVE-2021-4034, which they have called "Pwnkit"](https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt). While Alpine itself was not directly vulnerable to this issue due to different engineering decisions made in the way musl and glibc handle SUID binaries, this is intended to be a deeper look into what went wrong to enable successful exploitation on GNU/Linux systems.
|
|
|
|
## a note on blaming systemd
|
|
|
|
Before we get into this, I have seen a lot of people on Twitter blaming systemd for this vulnerability. It should be clarified that systemd has basically nothing to do with polkit, and has nothing at all to do with this vulnerability, systemd and polkit are separate projects largely maintained by different people.
|
|
|
|
We should try to be empathetic toward software maintainers, including those from systemd and polkit, so writing inflammatory posts blaming systemd or its maintainers for polkit does not really help to fix the problems that made this a useful security vulnerability.
|
|
|
|
## the theory behind exploiting CVE-2021-4034
|
|
|
|
For an idea of how one might exploit CVE-2021-4034, [lets look at blasty's "blasty vs pkexec" exploit](https://haxx.in/files/blasty-vs-pkexec.c). Take a look at the code for a few minutes, and come back here. There are multiple components to this exploit that have to all come together to make it work. A friend on IRC described it as a "rube goldberg machine" when I outlined it to him.
|
|
|
|
The first component of the exploit is the creation of a GNU iconv plugin: this is used to convert data from one character set to another. The plugin itself is the final step in the pipeline, and is used to gain the root shell.
|
|
|
|
The second component of the exploit is using `execve(2)` to arrange for `pkexec` to be run in a scenario where `argc < 1`. Although some POSIX rules lawyers will argue that this is a valid execution state, because the POSIX specification only says that `argv[0]` _should_ be the name of the program being run, I argue that it is really a nonsensical execution state under UNIX, and that defensive programming against this scenario is ridiculous, which is why I [sent a patch to the Linux kernel to remove the ability to do this](https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/T/).
|
|
|
|
The third component of the exploit is the use of GLib by `pkexec`. GLib is a commonly used C development framework, and it contains a lot of helpful infrastructure for developers, but that framework comes at the cost of a large attack surface, which is undesirable for an SUID binary.
|
|
|
|
The final component of the exploit is the design decision of the GLIBC authors to attempt to sanitize the environment of SUID programs rather than simply ignore known-harmful environmental variables when running as an SUID program. In essence, Qualys figured out a way to bypass the sanitization entirely. When these things combine, we are able to use `pkexec` to pop a root shell, as I will demonstrate.
|
|
|
|
## how things went wrong
|
|
|
|
Now that we have an understanding of what components are involved in the exploit, we can take a look at what happens from beginning to end. We have our helper plugin, which launches the root shell, and we have an understanding of the underlying configuration and its design flaws. How does all of this come together?
|
|
|
|
The exploit itself does not happen in `blasty-vs-pkexec.c`, that just sets up the necessary preconditions for everything else to fall into place, and then runs `pkexec`. But it runs `pkexec` in a way that basically results in an execution state that could be described as a weird machine: it uses `execve(2)` to launch it in an execution state where there are no arguments provided, not even an `argv[0]`.
|
|
|
|
Because `pkexec` is running in this weird state that it was never designed to run in, it executes as normal, except that we wind up in a situation where `argv[1]` is actually the beginning of the program's environment. The first value in the environment is `lol`, which is a valid argument, but not a valid environment variable, since it is missing a value. If we run `pkexec lol` in a terminal, we get:
|
|
|
|
\[kaniini@localhost ~\]$ pkexec lol
|
|
Cannot run program lol: No such file or directory
|
|
|
|
The reason why this is interesting is because that message is actually generated by `g_log()`, and that's where the fun begins. In initializing the GLog subsystem, there is a code path where `g_utf8_validate()` gets called on `argv[0]`. When running as a weird machine, this validation fails, because `argv[0]` is NULL. This results in GLib trying to convert `argv[0]` to UTF-8, which uses `iconv`, a libc function.
|
|
|
|
On GLIBC, the `iconv` function is provided by the GNU `libiconv` framework, which supports loading plugins to add additional character sets, from a directory specified as `GCONV_PATH`. Normally, `GCONV_PATH` is removed from an SUID program's environment because GLIBC sanitizes the environment of SUID programs, but Qualys figured out a way to glitch the sanitization, and so `GCONV_PATH` remains in the environment. As a result, we get a root shell as soon as it tries to convert `argv[0]` to UTF-8.
|
|
|
|
## where do we go from here?
|
|
|
|
On Alpine and other musl-based systems, we do not use GNU libiconv, so we are not vulnerable to blasty's PoC, and musl also makes a more robust decision: instead of trying to sanitize the environment of SUID programs, it just ignores variables which would lead to musl loading additional code, such as `LD_PRELOAD` entirely when running in SUID mode.
|
|
|
|
This means that ultimately three things need to be fixed: `pkexec` itself should be fixed (which has already been done), to close the vulnerability on older kernels, the kernel itself should be fixed to disallow this weird execution state (which my patch does), and GLIBC should be fixed to ignore dangerous environmental variables instead of trying to sanitize them.
|