|
|
Subscribe / Log in / New account

Linux nftables vulnerability exploited in the wild (CrowdStrike)

According to CrowdStrike, a vulnerability in the Linux kernel's nftables code that was discovered earlier this year is being actively exploited in the wild. The vulnerability allows for local privilege escalation. Most distributions have already released a fix.

As noted by the exploit developer, leveraging this POC is dependent on the kernel's unprivileged user namespaces feature accessing nf_tables. This access is enabled by default on Debian, Ubuntu and kernel capture-the-flag (CTF) distributions. An attacker can then trigger the double-free vulnerability, scan the physical memory for the kernel base address, bypass kernel address-space layout randomization (KASLR) and access the modprobe_path kernel variable with read/write privileges. After overwriting the modprobe_path, the exploit drops a root shell.


to post comments

It's hard to argue against memory safe programming languages (like Rust)

Posted Jun 9, 2024 19:38 UTC (Sun) by cyperpunks (subscriber, #39406) [Link] (3 responses)

Yet again very common issues in C/C++ creates large security problems.

The only sane way forward is to use better tools which detect such bugs at build time.

It's hard to argue against memory safe programming languages (like Rust)

Posted Jun 10, 2024 10:09 UTC (Mon) by WolfWings (subscriber, #56790) [Link]

I mean... that's literally what's being worked towards in the Linux kernel currently, with Rust no less?

It's hard to argue against memory safe programming languages (like Rust)

Posted Jun 11, 2024 7:10 UTC (Tue) by error27 (subscriber, #8346) [Link] (1 responses)

This code is pretty subtle. I think we're a long long ways away (check again in 20 years) from being able to detect the use after free this at compile time. You'd have to do it at runtime.

It's hard to argue against memory safe programming languages (like Rust)

Posted Jun 22, 2024 23:58 UTC (Sat) by mrugiero (guest, #153040) [Link]

I may have missed something (only skimmed the article), but it seems to me that this double free is not that subtle at all if your language enforces ownership. Either calling the function that does the packet drop requires passing ownership in the first place, making it impossible to call it a second time with the same object, or it requires shared ownership, increasing the reference count on entry, meaning only the caller can really free the underlying object. This particular bug wouldn't have happened with Rust AFAICT (or any other language with proper ownership semantics).

Looks like an ad.

Posted Jun 10, 2024 11:36 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link]

I'd classify this as advertisement (for CrowdStrikes mitigation services).


Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds