[l33tman]

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

[pizzalife]

> 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

[TacticalCoder]

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

[veonik]

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

[marcthe12]

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

[galangalalgol]

That is part of enabling rootless containers on rhel or similar.

[waynesonfire]

should have re-written it in rust.

[yjftsjthsd-h]

Rewritten what? The container runtime will need the same access regardless of what it's written in, and rewriting all of Linux (the kernel) would be... ambitious, although it is adopting rust incrementally.

[scns]

The good old Strangler Pattern.

https://martinfowler.com/bliki/StranglerFigApplication.html

[failsecure]

Yes and this decision haunts distros like Ubuntu over and over again. There's no easy win though.

[touisteur]

Do you need a user namespace? I'd expect a network namespace to be enough. Am I missing something?

Edit: should've read better, this seems to need CLONE_NEWUSER.

[jwilk]

You need CAP_SYS_ADMIN to create a new network namespace.

[jstanley]

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

[batch12]

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]

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.

[failsecure]

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.

[jstanley]

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

[thelastparadise]

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.

[pizzalife]

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

[hsbauauvhabzb]

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]

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.

[j_walter]

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.

[hsbauauvhabzb]

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.

[ikiris]

The link to the exploit accidentally went public. Anyone can have it.

[candiddevmike]

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]

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

[chasil]

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.

[withinboredom]

There is Ubuntu Pro which is free for up to five servers/desktops, after that, it requires a paid subscription.