Live data from Hacker News

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

seclists.org

71–80 of 107 posts

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

#71
post #42

Earlier quoted context omitted.

Alternatively, perhaps we should start thinking about whether it is a good idea to have multiple users of different privilege sharing the same hardware.

What's the alternative, just running all code at ring 0?

https://www.theseus-os.com/

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

#72

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.

Back in the day when the micro-kernel/monolith flamewars were raging, the arguments for monolith were about improved performance and lower memory usage. I haven't seen much discussion on this topic for years, but at least those two arguments have not aged well.

Why not? It isn't clear to me why monolithic kernel wouldn't still have better performance.

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

#73
post #69

Honest question: Why did they build an exploit that uses the bug? I always assumed that use-after-free is equivalent to "game over" (i.e. I assumed that local privilege escalation is a given) and it is clear that such a bug must be fixed. By that I mean, it might be easy or hard to exploit a bug to achieve LPE, but it seems to be redundant to prove that it is possible.

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.

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

#74
post #64

Earlier quoted context omitted.

Why would we need to slow seL4 down?

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.systems/projects/seL4/

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

#75
post #72

Earlier quoted context omitted.

Back in the day when the micro-kernel/monolith flamewars were raging, the arguments for monolith were about improved performance and lower memory usage. I haven't seen much discussion on this topic for years, but at least those two arguments have not aged well.

Why not? It isn't clear to me why monolithic kernel wouldn't still have better performance.

It doesn't matter with layers hypervisors, virtualization, containers and sandboxes running on top.

All mitigations to achieve microkernel like capabilities.

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

#76

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.

Back in the day when the micro-kernel/monolith flamewars were raging, the arguments for monolith were about improved performance and lower memory usage. I haven't seen much discussion on this topic for years, but at least those two arguments have not aged well.

Mostly because the cloud is based on microkernel like approach regardless of the kernel.

Hypervisors, userspace drivers, containers, language runtime sandboxes, bytecode deployments, driver and kernel sandboxes (safe kernel / driver guard),container only distributions,...

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

#77
post #32

Earlier quoted context omitted.

Probably depends on the distro. Iptables is a wrapper around nftables in most distros, but probably not all.

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.

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

#78
post #74

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…

The name-calling is uncalled for.

From an observer on the sidelines: there was no namecalling.

He said you trolled, not that you ate a troll. The distinction is important.

Even the best of us troll, sometimes. (Not claiming you did btw, just that there was no name calling.)

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

#79
post #73
post #69

Honest question: Why did they build an exploit that uses the bug? I always assumed that use-after-free is equivalent to "game over" (i.e. I assumed that local privilege escalation is a given) and it is clear that such a bug must be fixed. By that I mean, it might be easy or hard to exploit a bug to achieve LPE, but it seems to be redundant to prove that it is possible.

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.

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

#80

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.

Back in the day when the micro-kernel/monolith flamewars were raging, the arguments for monolith were about improved performance and lower memory usage. I haven't seen much discussion on this topic for years, but at least those two arguments have not aged well.

Spectre and friends seem to have killed Liedtke’s fast synchronous IPC, unfortunately. Of course, there’s still asynchronous IPC, exokernels (perhaps the closest thing to today’s containers), and so on.
Post reply on HN