After “Dirty Pipe”, Linux is Now Susceptible to “Dirty Creds”
While many were away enjoying some well-deserved R&R, security researchers, hackers wearing hats of all different colors, and intelligence agents from all over the world congregated at the Black Hat security conference.
As is often the case, some interesting new vulnerabilities were disclosed.
One of the vulnerabilities that was raised above the rest was introduced by a PhD student, Zhenpeng Li, and is a variation of “Dirty Pipe”, which was disclosed earlier this year – itself reminiscent of “Dirty Cow” from a few years ago.
This newly reported vulnerability was dubbed “Dirty Creds”. The jury is still out on the usefulness of naming specific vulnerabilities, but it happened.
Recalling “Dirty Pipe” (CVE-2022-0847), it was possible to overwrite (i.e., “dirty”) the content of a cache in kernel memory that would in turn overwrite the content of a file, even when no write permissions were assigned. This relied on exploiting the internal kernel mechanism that reads (and writes) to the cache, and – through some carefully selected flags – this would cause data chosen by an attacker to be written to any arbitrary file. There were some additional caveats, but the core problem was quickly exploited to elevate privileges in basically any given Linux system.
The new vulnerability (CVE-2022-2588) abuses another kernel functionality and provides a way to change the privileges that a given task runs with, regardless of the actual privileges that the user who initiated it has. This comes from a heap-abuse situation, where the kernel is tricked into writing different information into the memory location where credentials are stored (these are kernel-internal task credentials and open-file credentials, not the credentials a user has to log in to a system).
To be successful, an attacker has to wait for a combination of privileged and unprivileged credentials to be stored in a particular order in memory, but – since this also includes file-open operations – the system will often be in a susceptible state and may even be tricked into this situation if it doesn’t happen on its own.
One of the interesting, and potentially more damaging, aspects of this new vulnerability is that the code to exploit it works unchanged among different architectures (not just x86_64). As a result, systems that usually evade memory corruption and related issues like this (simply because they have different memory structures) are also at risk. This is a departure from traditional exploits that have to be custom coded for every particular CPU architecture to account for differences in memory alignment, instruction count or other more esoteric characteristics.
The status of the KernelCare Enterprise patches that protect against “Dirty Creds” for the different distributions and kernel versions affected can be monitored at https://cve.tuxcare.com/live?cve=2022-2588.
Unfortunately, not only has the vulnerability been disclosed and discussed extensively, but public exploit code has already been found, so all systems should be patched against it as soon as possible.