Red Hot Cyber
Cybersecurity is about sharing.
Recognize the risk, combat it, share your experiences,
and encourage others to do better than you.
Menu
Sergio Corpettini : 6 April 2024 08:49
Traslate: Antonio Piovesan
On X, Lau (@notselwyn) (https://twitter.com/notselwyn/) released a blogpost on 26 March at https://pwning.tech/nftables/ describing an elaborate attack on the Linux kernel that allows privilege escalation by exploiting a vulnerability in nf_tables. The POC, published on Github, starting with a double free() leads the kernel to execute arbitrary code with root privileges.
A privilege escalation attack makes it possible, starting from user privileges, to obtain higher privileges, usually administrator privileges, or root privileges.
The kernel is the first layer of software that ’embraces’ and protects the hardware. In modern operating systems, one of its most important tasks is to keep processes in separate and protected ‘islands’. In some cases, a process needs access to ‘privileged’ resources, in which case it can politely ask the kernel to execute the request with its ‘superpowers’ and then respond to the calling process with the result, without the need to run the entire process with elevated privileges.
Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765
Supporta RHC attraverso:
A Kernel Exploit directly attacks this chain of communication between userland and kernel, managing to make the kernel execute something it should not, resulting in the execution of code from userland with kernel privileges. But let’s look at a few more details.
The linux kernel also takes care of network security, it ‘sits’ directly on the network cards, analyses the traffic and applies the rules of the internal firewall. The firewall rules are defined via Netfilter.
@notselwyn started the ‘dialogue’ with the kernel by setting a new Netfilter rule forged ad hoc from userland that forces the kernel to free an area of memory twice in a row (the double free() mentioned at the beginning).
It then starts saturating the kernel with packages forged specifically to impact that rule. At this point, the kernel is very confused: by forcing it to free an area of memory twice in a row, the userland process will be able to access that memory using a pointer that theoretically should no longer be accessible. This gives the userland process access to privileged memory areas. There are mechanisms in the kernel that are supposed to protect against this kind of attack, but by using techniques that go beyond the scope of this article (I refer you to the article by the researcher who discovered this bug, https://pwning.tech/nftables/ for more details), it is possible to evade the prevention checks and get the kernel to ‘force its hand’ and make it execute arbitrary code with elevated privileges. Arbitrary code in the kernel means full access to everything: Bingo! You are an administrator.
The use-after-free vulnerability in the Netfilter component of the Linux kernel has been catalogued as CVE-2024-1086. The CVE impacts most “vanilla” linux kernel versions 5.15.y 6.1.y and 6.6.y.
A bugfix for this vulnerability has been included in the stable branches of the kernel as of February 2024. The impact is HIGH (CVSSv3 7.8) as it is a direct attack on the kernel and covers a “vanilla” configuration that many distributions use. In the context of Linux kernel development, the ‘vanilla’ kernel is the kernel officially distributed by Linus Torvalds and the Linux designers, without any additional patches.
Regularly update the kernel to the latest stable version on all your Linux machines. Kernel updates, especially in LTE versions, are critical and must be treated with the utmost urgency. The maxim ‘if it works, don’t touch it’ does not apply to this kind of update: a policy of system backups is indispensable, as is testing before sending changes into production, but maintaining your systems, even home systems, with an acceptable security posture is imperative.
In addition, another consideration, perhaps an ‘old school’ piece of advice if you will, could be to try to keep the kernel in use as ‘minimal’ as possible: recompile it for the machine on which it runs with only the modules that you really need; this is something that may be difficult to implement, especially in environments where you have to manage many heterogeneous systems.
Sergio Corpettini