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

https://seclists.org/oss-sec/2023/q2/133

by kuizu • 3 years ago

288 101 3 years ago

seclists.org

alex14fr2• 3 years ago

Glad to have sticked with the good old iptables and left CONFIG_NF_TABLES unset in kernel configuration.

sam_lowry_• 3 years ago

Aren't iptables just an emulation layer on top of netfilter?

eikenberry• 3 years ago

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

TechBro8615• 3 years ago

Yes, AFAIU (not an expert), iptables and nftables are two command line tools and abstractions (chains vs. tables) for interacting with the same underlying netfilter API.

failsecure3• 3 years ago

For modern distros, the nft package includes an alternative binary that takes the place of /sbin/iptables and translates the input to an nft compatible format. As far as the kernel is concerned, iptables is still iptables. Old iptables can be accessed by calling the iptables-legacy binary which will auto load the old iptables ko.

knorker• 3 years ago

delete an existing nft rule that uses an nft anonymous set. And an example of the latter operation is an attempt to delete an element from that nft anonymous set after the set gets deleted

I'd be very interested to hear how this can be done by an unprivileged user.

Try to race set add/removals, sure, but if it depends on the set itself getting deleted, that seems… harder.

0x006A• 3 years ago

on https://bugzilla.redhat.com/show_bug.cgi?id=2196105 a comment suggests that it might only be possible if you have "unprivileged user namespaces" enabled

pizzalife3• 3 years ago

a comment suggests that it might only be possible if you have "unprivileged user namespaces" enabled

Which is the default on Ubuntu.

l33tman• 3 years ago

"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 <security () kernel org> to assist with fix development. Somebody from the Linux kernel team then emailed the proposed fix to <linux-distros () vs openwall org> 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, I intend to publish both the description of exploitation techniques and also the exploit source code on Monday 15th by email to this list."

Interesting.. they didn't write what conditions have to be met for it to be exploitable. Also interesting that someone screwed up and accidentally forwarded an email including the exploit to a broad mailing list...

Part of the nf modules are active if you have iptables, which you have if you run ufw (for example), so pretty broad exploit if that's all that's required, 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.

pizzalife3• 3 years ago

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:~% lsmod|grep nf_table
  ubuntu:~% unshare -U -m -n -r
  ubuntu:~% nft add table inet filter
  ubuntu:~% lsmod|grep nf_table
  nf_tables             249856  0

veonik• 3 years ago

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

TacticalCoder• 3 years ago

For comparison, on my Debian Bookworm (aka "testing" but in hard freeze and full freeze in a few days I think, stable release in june) here...

    ...$  lsmod|grep nf_table    (tried without any just to make sure) 
    ...$  unshare -U -m -n -r
    unshare: unshare: failed: Operation not permitted
    ...$  /sbin/nft add table inet filter
    Error: Could not process rule: Operation not permitted
    add table inet filter
    ^^^^^^^^^^^^^^^^^^^^^^

    root #  cat /proc/sys/kernel/unprivileged_userns_clone
    0

thelastparadise• 3 years ago

I don't think the bug itself is newsworthy. The existence of the exploit code, and the way that it was accidentally published, I think are.

pizzalife3• 3 years ago

It's exploitable by an unprivileged user on the most popular distro out there (Ubuntu). I would say it's newsworthy.

hsbauauvhabzb2• 3 years ago

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)

sp332• 3 years ago

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.

candiddevmike• 3 years ago

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.

krastanov• 3 years ago

The thing is already in the wild because someone on the private mailing list already accidentally mailed it to the public mailing list.

chasil• 3 years ago

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.

jstanley2• 3 years ago

Somebody from the Linux kernel team then emailed the proposed fix to <linux-distros () vs openwall org> 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 mailing list, and this somehow creates an obligation on you to follow that mailing list's policies? I don't get it.

failsecure3• 3 years ago

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.

batch12• 3 years ago

Maybe they consider the exploit is in the wild when sending to a distro that large[0] with recipients that aren't provably trustworthy.

[0] https://oss-security.openwall.org/wiki/mailing-lists/distros

amatecha• 3 years ago

I believe they are referring to this:

https://oss-security.openwall.org/wiki/mailing-lists/distros

Please note that the maximum acceptable embargo period for issues disclosed to these lists is 14 days. Please do not ask for a longer embargo. In fact, embargo periods shorter than 7 days are preferable.

AdamJacobMuller• 3 years ago

https://nvd.nist.gov/vuln/detail/CVE-2023-32233

The NIST CVE page points back here. Funny.

Nothing I see so far specifically says how far back this goes, but, https://security-tracker.debian.org/tracker/CVE-2023-32233

Seems to go back really far.

fnordpiglet• 3 years ago

Rust needs to be more prominent in the kernel, and where not rust ebpf. The days of hand mangling pointer arithmetic need to end.

eklitzke2• 3 years ago

The patch doesn't fix anything with pointer arithmetic: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

wtallis2• 3 years ago

I wouldn't generally expect a use-after-free to result from improper pointer arithmetic; that's the recipe for a buffer overflow. But Rust happens to also be well-known for helping manage object lifetimes, which seems to be what went wrong here.

snvzz6• 3 years ago

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.

unixhero• 3 years ago

Well it is the kernel.

Gigachad• 3 years ago

We really need to be moving faster on migrating Linux to a safer language which prevents these kinds of issues.

0cf8612b2e1e• 3 years ago

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.

anonymousiam• 3 years ago

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.

galangalalgol3• 3 years ago

For rack servers you could probably get away with a number of microkernel os today. Desktop has clear options in that regard, but you are giving up op n source.

CorbetL• 3 years ago

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

phendrenad2• 3 years ago

Actually over 30 million LOC

userbinator2• 3 years ago

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

thfuran• 3 years ago

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

travis729• 3 years ago

I’ve been thinking this recently as well.

gizmo686• 3 years ago

"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.

akvadrako• 3 years ago

It won't make that big of a difference. If you exploit the networking layer you could intercept any local traffic, which will mostly be unencrypted, and communicate with outside attackers. You are probably owned by that point unless you treated localhost as untrusted.

It's like why it doesn't matter if you are running as root or not. The user account has access to whats important, like a database or keychain.

saagarjha4• 3 years ago

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

snvzz6• 3 years ago

Why would we need to slow seL4 down?

explorer83• 3 years ago

Based on this 11 month old discussion this has been an exploit vector for sometime - https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3...

"I vaguely recall at least around 6-7 such holes, and a quick google search seems to reveal that at least those would have been mitigated by unprivileged user namespaces being disabled: CVE-2019-18198 CVE-2020-14386 CVE-2022-0185 CVE-2022-24122 CVE-2022-25636 CVE-2022-1966 resp. CVE-2022-32250"

moring3• 3 years ago

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.

mort963• 3 years ago

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.

moring3• 3 years ago

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.

igo95862• 3 years ago

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.

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

Related Stories