Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux kernel use-after-free in Netfilter, local privilege escalation

seclists.org

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#91

Post by withinboredom »

klooney wrote: post #56
chlorion wrote: post #20

Earlier quoted context omitted.

It's the default on pretty much any modern Linux system!

From 2016- https://lwn.net/Articles/673597/ Andy Lutomirski described some concerns of his own: > I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN over /any/ network namespace and to thus access the network configuration API to be a huge risk. For example, unprivileged users can program iptables. I'll eat my hat if there are no privilege escalations in there.

I hope he hasn't been eating his hat all these years. I hear that isn't good for the digestive system... /s

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#92

Post by mort96 »

moring wrote: post #79
mort96 wrote: post #73

Earlier quoted context omitted.

Making a PoC is a great way to convince both yourself and the maintainers that the bug is actually exploitable in the wild and thus a big fucking deal. Alternatively, you might discover that there are some other things going on which turns out to make the bug unexploitable.

Let me rephrase my question: Is there actually such a thing as an "unexploitable use-after-free"? How would that look like? How would you reason that it is actually unexploitable? Context: My experience with C programming is that practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.

Here's a stupid example:

    struct foo *whatever = new_foo();
    // use 'whatever'
    free_foo(whatever);
    if (whatever->did_something) {
        log_message("The whatever did something.");
    }
    // never use 'whatever' after this point
The 'whatever' variable is used after what it points to is freed, but it's not exploitable. Worst case, if new memory gets allocated in its place and an attacker controls the data in the offset of the 'did_something' field, the attacker can control whether we log a message or not, which isn't a security vulnerability.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#93

Post by jstanley »

failsecure wrote: post #45
jstanley wrote: post #44

Earlier quoted context omitted.

> Somebody from the Linux kernel team then emailed the proposed fix to and that email also included a link to download our description of exploitation techniques and our exploit source code. > Therefore, according to the linux-distros list policy, the exploit must be published within 7 days from this advisory. In order to comply with that policy, [...] What? Someone publishes information about your vuln to a random m…

Maybe linux-distros has a poc or GTFO rule in place to keep the unchecked "I can get root on your box with this one weird trick but I won't tell you how" emails to a minimum. Just a guess though.

That's fine. They didn't want it on linux-distros anyway!

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#94

Post by pjmlp »

aflag wrote: post #84
pjmlp wrote: post #75

Earlier quoted context omitted.

It doesn't matter with layers hypervisors, virtualization, containers and sandboxes running on top. All mitigations to achieve microkernel like capabilities.

Hm, if you're making the underlying hardware slower, don't you want the kernel to be even faster though? VMs are much more than micro kernels. It's about allowing the user to install whatever they want in their machine. Containers are just a userland abstraction. Not sure where the link to microkernels is there.

Not when using hypervisor type 1.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#95

Post by moring »

mort96 wrote: post #92
moring wrote: post #79

Earlier quoted context omitted.

Let me rephrase my question: Is there actually such a thing as an "unexploitable use-after-free"? How would that look like? How would you reason that it is actually unexploitable? Context: My experience with C programming is that practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.

Here's a stupid example: struct foo *whatever = new_foo(); // use 'whatever' free_foo(whatever); if (whatever->did_something) { log_message("The whatever did something."); } // never use 'whatever' after this point The 'whatever' variable is used after what it points to is freed, but it's not exploitable. Worst case, if new memory gets allocated in its place and an attacker controls the data in the offset of the 'did…

What happens if the code gets pre-empted between free_foo(whatever) and the if-statement, memory allocation gets changed, and subsequently dereferencing the pointer to read whatever->did_something causes a page fault?

I am making assumptions here: That pre-emption is possible (at least some interrupts are enabled), that "whatever" points to virtual memory (some architectures have non-mappable physical memory pointers), and that a page fault at this point is actually harmful.

However I do want to point out that the reasoning why your example is not exploitable isn't as easy as it first seems.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#96

Post by mort96 »

moring wrote: post #95
mort96 wrote: post #92

Earlier quoted context omitted.

Here's a stupid example: struct foo *whatever = new_foo(); // use 'whatever' free_foo(whatever); if (whatever->did_something) { log_message("The whatever did something."); } // never use 'whatever' after this point The 'whatever' variable is used after what it points to is freed, but it's not exploitable. Worst case, if new memory gets allocated in its place and an attacker controls the data in the offset of the 'did…

What happens if the code gets pre-empted between free_foo(whatever) and the if-statement, memory allocation gets changed, and subsequently dereferencing the pointer to read whatever->did_something causes a page fault? I am making assumptions here: That pre-emption is possible (at least some interrupts are enabled), that "whatever" points to virtual memory (some architectures have non-mappable physical memory pointers…

No preemption is needed, the call to free might unmap the page the pointer points to. I was considering adding a paragraph about that but didn't bother. A page fault isn't a privilege escalation issue though, it's a pretty normal thing.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#97

Post by ttarr »

CorbetL wrote: post #48
0cf8612b2e1e wrote: post #33

Earlier quoted context omitted.

Microkernel does seem the only sensible path forward. Even if the kernel is slowly rustified, going to be playing security whack-a-mole for a long time.

Linux may eventually become a microkernel with most IPC done via io_uring, but it may take 20 years to reach this state.

Care to elaborate plz?

How would we go about GPUs, NCs, and many kinds of drivers?

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#98

Post by arp242 »

snvzz wrote: post #74
saagarjha wrote: post #65

Earlier quoted context omitted.

I'm not really in the mood for trolling.

The name-calling is uncalled for. To elaborate, seL4 claims to be the fastest kernel around[0], a claim that remains unchallenged. To put it into context, the difference in IPC speed is such that you'd need an order of magnitude more IPC for a multiserver system based on seL4 to actually be slower than Linux. A multiserver design would imply increased IPC use, but not an order of magnitude. 0. https://trustworthy.sys…

> To elaborate, seL4 claims to be the fastest kernel around[0], a claim that remains unchallenged.

Can I run Firefox or PostgreSQL on seL4? Or another real-world program of comparable complexity? And how does the performance of that compare to Linux or BSD?

That's really the only benchmark that matters; it's not hard to be fast if your kernel is simple, but simple is often also less useful. Terry Davis claimed TempleOS was faster than Linux, and in some ways he was right too. But TempleOS is also much more limited than Linux and, in the end, not all that useful – even Terry ran it inside a VM.

I've heard these sort of claims about seL4 before, and I've tried to look up some more detailed information about seL4 before, and I've never really found anything convincing on the topic beyond "TempleOS can do loads more context switches than Linux!" type stuff.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#99

Post by igo95862 »

I am developing a sandbox project for Linux desktop applications called bubblejail:

https://github.com/igo95862/bubblejail

In the next not yet released version 0.8.0 there will be a new option to disable a specific namespace type per sandbox. For example, disabling the network namespace would prevent this exploit.

This is more flexible than globally disabling all user namespaces as some programs might use other more harmless namespaces like Steam uses mount namespaces to setup runtime libraries.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#100

Post by smashed »

ahartmetz wrote: post #77
smashed wrote: post #32

Earlier quoted context omitted.

You can check with: iptables -V If it says (nf_tables), you are using the compatibility layer from the iptables-nft package. It works quite well. Apps like Docker that inserts rules using the legacy iptables syntax are oblivious to the fact that they are actually inserting nftables rules. It also provides an easy migration path. Insert your old rules using your iptables script then list them in the new syntax using n…

IMO, the problem is that the people who created nftables (and the "ip" tool) couldn't create a user interface that anyone but themselves would like to use. Linux traffic shaping functionality suffers from the same "obscure word soup" interface.

I agree for the "ip" tool (from iproute2).. I got used to it but I still prefer the ifconfig output. It is somehow consistant and you can get used to it.

I somehow got accustomed to the nftables rules format. It is in fact objectively much better than the iptables format in many ways. The native JSON, easy bulk submit to the kernel, built-in sets and maps (the source of the currently discussed CVE though). It really does fix a lot of what was wrong with iptables.

But iptables was probably not broken enough for most users to warrant re-learning everything.

Now, the traffic shaping tool, oof.. I still cannot grok any of it. I've been happy with the fireqos script so far to abstract everything out of the tc syntax.

Post reply on HN