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

51–60 of 107 posts

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

#51

Post by gizmo686 »

userbinator wrote: post #38
snvzz wrote: post #28

There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.

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

"User" in a modern Linux system is just a weird name for "security domain". Many programs run as their own user to limit their ability to attack the rest of the system if they get compromised; and limit the ability of a different compromised component from attacking them.

My desktop, on which I am the only person with an account, has 49 "users", of which 11 are actively running a process.

At work, every daemon we run has a dedicated user.

On android, every app runs as its own user.

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

#52

Post by chasil »

candiddevmike wrote: post #15
l33tman wrote: post #8

"We developed an exploit that allows unprivileged local users to start a root shell by abusing the above issue. That exploit was shared privately with to assist with fix development. 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 p…

What a dumb policy. Why have the disclosure time be so soon? This thing will be in the wild before folks can upgrade if I'm understanding this correctly.

You have a few options for dealing with problems like this.

You can "apt update; apt upgrade" then reboot when a new kernel is available.

Oracle has also offered Ksplice for free on Ubuntu for many years, and I'm sure that patch will be available promptly.

https://ksplice.oracle.com/try/desktop

Otherwise, Kernelcare is available for a fee. I think Canonical also has paid kernel patches.

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

#53

Post by userbinator »

thfuran wrote: post #42
userbinator wrote: post #38

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?

IMHO rings 0 + 3 with protections against bugs, and not deliberate malice, is probably the sweet spot.

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

#54

Post by j_walter »

sp332 wrote: post #27
hsbauauvhabzb wrote: post #14

Earlier quoted context omitted.

What’s actually reasonable here. I’m all for exploit code becoming public eventually, but I think it’s silly to drop it immediately after a fix has been released, or before, in almost all scenarios (unless there’s been 90+ days or the issue marked as wontfix)

Odds are that well-resourced attackers already have the exploit by now. Making it public lets users decide if this is important to them and come up with their own mitigations.

Once they issue the patch...it's only a matter of time till a good chunk of reasonably decent coders can develop the exploit. Once the premise is released...yeah the top exploit coders will have this in a few hours.

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

#55

Post by max_k »

comex wrote: post #34
eklitzke wrote: post #25

Earlier quoted context omitted.

I'm not sure if your claim here is correct. The patch is to change call sites like priv->set->use++; To look like: nf_tables_activate_set(ctx, priv->set); Where this function is defined as: void nf_tables_activate_set(const struct nft_ctx *ctx, struct nft_set *set) { if (nft_set_is_anonymous(set)) nft_clear(ctx->net, set); set->use++; } So to me (someone who is not an expert in this code) it looks like the fix is che…

One of the parts of Rust’s safety story is to always use smart pointers for reference counting rather than the type of ad-hoc manual reference count management seen in the code you quoted. Combined with lifetime checking, it makes it impossible for some random logic error to cause a use-after-free.

> to always use smart pointers for reference counting

Agree - and the Linux kernel is extremely fragile because it is full of ad-hoc manual code like that.

Unfortunately, Rust won't be the rescue, because (in the foreseeable future) Rust will only be available in leaf code due to the many hard problems of transitioning from fragile C APIs to something better. Writing drivers in Rust is useful, but limits the scope of how Rust helps.

Many of Rust's advantages at a tiny fraction of the effort could be had easily with a smooth transition path by switching the compiler from C to C++ mode. The fruit hangs so low, it nearly touches the ground, but a silly Linus rejects C++ for the wrong reasons ("to keep the C++ programmers out", wtf).

Every time I work on the Linux kernel source, I'm horrified by how much pain the kernel developers inflict on themselves. Even with C, it would be possible to install a mandatory coding style that is less fragile.

For example, in the aftermath of the Dirty Pipe vulnerability last year, I submitted a patch to make the code less fragile, a coding style that would have prevented the vulnerability: https://lore.kernel.org/lkml/20220225185431.2617232-4-max.ke... - but my patch went nowhere.

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

#56

Post by klooney »

chlorion wrote: post #20
pizzalife wrote: post #11

Earlier quoted context omitted.

>a comment suggests that it might only be possible if you have "unprivileged user namespaces" enabled Which is the default on Ubuntu.

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.

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

#57

Post by saagarjha »

snvzz wrote: post #28

There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.

Who's going to make seL4 perform comparably to Linux?

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

#58

Post by marcthe12 »

veonik wrote: post #19
pizzalife wrote: post #10

Earlier quoted context omitted.

> but the specific module in question in the patch, nf_tables, is not loaded on my Ubuntu 20.04LTS 5.40 kernel running iptables/ufw at least This doesn't matter since Linux has autoloading of most network modules, and you can cause the modules to be loaded on Ubuntu since it supports unprivileged user/net namespaces. ubuntu:~% grep DISTRIB_DESCRIPTION /etc/lsb-release DISTRIB_DESCRIPTION="Ubuntu 22.04.2 LTS" ubuntu:~…

Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?

Most, I think Debian has patch to be disabled at runtime via sysctl. The reason is that most containers or sandboxing techniques are root only unless you mix it with user namescapes. So most container or sandbox software use suid(firejail) , root daemon(docker) or user namescapes (podman and flatpak). Looking at the cves, user namespaces is probably the safer option

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

#59

Post by comex »

max_k wrote: post #55
comex wrote: post #34

Earlier quoted context omitted.

One of the parts of Rust’s safety story is to always use smart pointers for reference counting rather than the type of ad-hoc manual reference count management seen in the code you quoted. Combined with lifetime checking, it makes it impossible for some random logic error to cause a use-after-free.

> to always use smart pointers for reference counting Agree - and the Linux kernel is extremely fragile because it is full of ad-hoc manual code like that. Unfortunately, Rust won't be the rescue, because (in the foreseeable future) Rust will only be available in leaf code due to the many hard problems of transitioning from fragile C APIs to something better. Writing drivers in Rust is useful, but limits the scope of…

We’ll see. As far as I know, the biggest blocker to using Rust outside of drivers is the fact that LLVM lacks support for some architectures Linux supports. And rustc_codegen_gcc seems on track to fix that eventually; even if it takes years more, that’s not much time on the scale of Linux’s development history.

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

#60

Post by hsbauauvhabzb »

j_walter wrote: post #54
sp332 wrote: post #27

Earlier quoted context omitted.

Odds are that well-resourced attackers already have the exploit by now. Making it public lets users decide if this is important to them and come up with their own mitigations.

Once they issue the patch...it's only a matter of time till a good chunk of reasonably decent coders can develop the exploit. Once the premise is released...yeah the top exploit coders will have this in a few hours.

So we lower the bar to all adversaries with no benefit?

If you can read exploit code to determine if patching is worth it for your use case, you can probably also read diffs for the same outcome.

I’m not saying don’t release them, but releasing them with short notice seems irresponsible, without much benefit to defenders.

Post reply on HN