LWN: Comments on "A local root kernel vulnerability"

A local root kernel vulnerability

wtarreau — Sat, 24 Jul 2021 10:14:32 +0000

> I understand the kernel people are worried that mentioning known exploits for some bugs would give people a false sense of security about other ones, but I think that's a highly questionable argument. If you're fixing a known exploit, let people know!

It's not that much of a questionable argument, as I've already heard coworkers say "this afternoon I'll have to check if there are any glibc CVEs and backport fixes". I've heard that at customers' too. And I'm pretty sure that this horrible practice is extremely common. You can repeat as much as you want that lack of report doesn't mean absence, but no, people stick to this as if they were doing the minimum needed to avoid being blamed.

There might be something doable though. In haproxy we classify bugs in 4 levels of severity: minor (easy to work around, or minimal impact that can be ignored), medium (cannot easily ignore, may require non-trivial workaround or to temporarily disable a seldom used feature), major (severe impact such as a crash, no practical workaround without a total loss of important feature or severe performance regression), critical (like major but remotely triggerable). For each stable version we provide the number of bugs in each category. This instantly provides a good level of estimate about the importance of upgrading or not. A lot of users don't upgrade if they don't see a major or critical one, and are not facing production issues, and I think that's OK, because they simply trust the developers' feelings about the bugs that were fixed.

In the kernel we could possibly do the same. I really don't care if a known exploit exists quite frankly. However knowing that a nasty bug can cause some memory corruption already means that someone can trigger it to render my system unstable, and possibly gain extra privileges. Whether the bug finder was interested in working on an exploit or not is irrelevant there, and someone else might perfectly do later. And for the users, knowing that "pretty bad bugs" were fixed compared to another version which only fixed minor ones such as wifi reconnection issues, it useful. All this is not about security, just severity. However security also depends on severity.

A local root kernel vulnerability

geuder — Thu, 22 Jul 2021 17:41:39 +0000

Ah, sudo lsns -t user. I probably knew that one day.

And I was so proud about my oneliner :)

A local root kernel vulnerability

jezuch — Thu, 22 Jul 2021 16:06:18 +0000

> Or we could assign numbers to those well-known arguments. Then it would go:
> Alice: 136!
> Bob: 155!
> Alice: 136!

Even that idea isn't new

https://en.wikipedia.org/wiki/The_Futurological_Congress

"""
The conference itself is no less absurd. Papers and presenters are too numerous to allow for full presentations. Instead, papers are distributed in hard copy and speakers call out paragraph numbers to call attention to their most salient points.
"""

A local root kernel vulnerability

immibis — Thu, 22 Jul 2021 10:20:53 +0000

Perhaps we could label them as Common Vindictive Exchanges, and we could number them with the year they were introduced and a yearly resetting sequence number, such as CVE-2021-0001

A local root kernel vulnerability

grawity — Thu, 22 Jul 2021 04:34:20 +0000

> On my current pretty fat Arch desktop I have uses them for sandboxing, as does :

Uhh. Thanks, middle-click paste or something.

A local root kernel vulnerability

grawity — Thu, 22 Jul 2021 04:33:38 +0000

Just like Firefox, both Chrome and Flatpak use them for sandboxing (the latter using the bwrap tool under the hood). Upowerd actually does not use namespaces on its own, but its systemd unit enables PrivateUsers= as a generic "hardening" option.

On my current pretty fat Arch desktop I have uses them for sandboxing, as does :

$ sudo lsns -t user
        NS TYPE  NPROCS   PID USER    COMMAND
4026531837 user     262     1 root    /usr/lib/systemd/systemd --system --deserialize 44
4026532633 user       1   880 root    /usr/lib/upowerd
4026532706 user       1  2920 grawity /opt/google/chrome/nacl_helper
4026532707 user      18  2919 grawity /opt/google/chrome/chrome --type=zygote
4026532720 user       1 80470 grawity xdg-dbus-proxy --args=40
4026532804 user       2 80475 grawity bwrap --args 38 gnome-text-editor

A local root kernel vulnerability

geuder — Wed, 21 Jul 2021 18:40:16 +0000

Thanks for the detailed reply. I had missed the change between Debian 10 and 11.

I wasn't aware that so many applications use user namespaces these days.

On my current pretty minimalistic Xubuntu desktop I have:

$ ps $(sudo find /proc/ -path "*/ns/user" -exec ls -l {} + | grep -v 4026531837 | sed 's,.*/proc/\([0-9]*\)/.*,\1,' | sort -u)
    PID TTY      STAT   TIME COMMAND
   1488 ?        Ssl    0:00 /usr/lib/upower/upowerd
   1917 ?        Sl     0:02 /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 240473 -jsInit 285176 -parentBuildID 20210705185941 -appdir /usr/lib/firefox/browser 1755 true tab
   1983 ?        Sl     0:04 /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 5013 -prefMapSize 240473 -jsInit 285176 -parentBuildID 20210705185941 -appdir /usr/lib/firefox/browser 1755 true tab
   2042 ?        Sl     0:07 /usr/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 5673 -prefMapSize 240473 -jsInit 285176 -parentBuildID 20210705185941 -appdir /usr/lib/firefox/browser 1755 true tab
   2098 ?        Sl     0:32 /usr/lib/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 8137 -prefMapSize 240473 -jsInit 285176 -parentBuildID 20210705185941 -appdir /usr/lib/firefox/browser 1755 true tab
   2199 ?        Sl     0:00 /usr/lib/firefox/firefox -contentproc -parentBuildID 20210705185941 -prefsLen 8863 -prefMapSize 240473 -appdir /usr/lib/firefox/browser 1755 true rdd
   2202 ?        Sl     0:09 /usr/lib/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 8863 -prefMapSize 240473 -jsInit 285176 -parentBuildID 20210705185941 -appdir /usr/lib/firefox/browser 1755 true tab
   2470 ?        Sl     0:11 /usr/lib/firefox/firefox -contentproc -childID 7 -isForBrowser -prefsLen 9453 -prefMapSize 240473 -jsInit 285176 -parentBuildID 20210705185941 -appdir /usr/lib/firefox/browser 1755 true tab
   2555 ?        Sl     0:00 /usr/lib/firefox/firefox -contentproc -childID 8 -isForBrowser -prefsLen 9453 -prefMapSize 240473 -jsInit 285176 -parentBuildID 20210705185941 -appdir /usr/lib/firefox/browser 1755 true tab

I know podman uses them, too, but there is no container running now.

A local root kernel vulnerability

smcv — Wed, 21 Jul 2021 12:59:46 +0000

> Didn't the known exploit require an unprivileged user namespace? I thought they were not supported in the Debian kernel.

In Debian <= 10 they're disabled by default and require special configuration.

In Debian >= 11 they're enabled by default, because applications that do sandboxing (notably web browsers) and container tools (notably podman and toolbox) increasingly require them, but can be disabled with special configuration (at the cost of breaking those applications and tools).

A side benefit is that we no longer require a setuid-root executable to enter a useful container environment (notably bwrap for Flatpak, WebKitGTK, GNOME thumbnailers, Steam games, etc., and schroot for unprivileged Debian package builds).

It's a security trade-off: disabling unprivileged creation of user namespaces mitigates vulnerabilities like this one, but enabling unprivileged creation of user namespaces can reduce various other attack surfaces, as well as providing more functionality.

A local root kernel vulnerability

epa — Wed, 21 Jul 2021 10:29:41 +0000

Surely you make the commit, with informative commit message, and then push it to a public git server at the moment of the coordinated release? If you're working with others who are also under embargo, and want to get new kernel packages ready in advance of the release date, you can share your git repository with them privately.

Right now we seem to have the worst of both worlds: the information on the vulnerability gets leaked before the disclosure date, because anyone with enough time and skill can review the diffs. Yet once the bug is disclosed and it should be straightforward to see which security fixes have been included in a tree, you have to deal with deliberately vague commit messages.

A local root kernel vulnerability

NAR — Wed, 21 Jul 2021 10:07:35 +0000

"Why not say clearly "this is an exploitable security bug" instead of pussyfooting around? "

Because they have(?) to do the commit before the coordinated release date.

A local root kernel vulnerability

oldtomas — Wed, 21 Jul 2021 08:31:51 +0000

It would be nice if people wouldn't start a well-known discussion as if it were new. Each and every time.

Positions are known by now. Without an all-new argument, they don't seem bound to change. Perhaps it's time to find a way to get along with this difference, instead of rehashing ad nauseam.

Or we could assign numbers to those well-known arguments. Then it would go:

Alice: 136!
Bob: 155!
Alice: 136!
...

A local root kernel vulnerability

vegard — Wed, 21 Jul 2021 07:46:54 +0000

The linked advisory seems to name the vulnerability "Sequoia".

A local root kernel vulnerability

pbonzini — Wed, 21 Jul 2021 06:24:34 +0000

On a locked down system (secure boot), even if something required root it would be a privilege escalation.

A local root kernel vulnerability

geuder — Wed, 21 Jul 2021 06:19:23 +0000

Didn't the known exploit require an unprivileged user namespace? I thought they were not supported in the Debian kernel. Or do I remember that wrong? I have no Debian kernel handy to try.

The article says Debian would be exploitable.

Commit messages

roc — Wed, 21 Jul 2021 00:01:22 +0000

Black hats are watching Linux commits and doing their own analysis of exploitability. Given that, there is usually no harm in explicitly saying in the commit message "this fixes an exploitable security bug", and that would make the priority of fixing this clear to everyone.

I can see a case for being vague when it's very nonobvious that the bug is exploitable. But that should be a high bar.

A local root kernel vulnerability

roc — Tue, 20 Jul 2021 23:58:27 +0000

Why not say clearly "this is an exploitable security bug" instead of pussyfooting around? That makes the priority of the fix clear to all possible downstream consumers.

For sure there are multiple black hats watching the commit logs closely already. Being deliberately vague in the commit message doesn't stop attacks and only muddies the waters for people who don't watch so closely.

A local root kernel vulnerability

Duncan — Tue, 20 Jul 2021 21:36:21 +0000

Come on. The commit message includes the "buffer" keyword along with "avoids int overflow pitfalls". Particularly in kernel context how can that *not* be a "bug with security implications"? Seems they effectively "came right out and said it" to me.

Keeping in mind that the commit and therefore by definition the commit message was pre-disclosure (if not by much), in what way would a "perfect" commit message have differed?

A local root kernel vulnerability

khim — Tue, 20 Jul 2021 21:05:18 +0000

True, but if we are talking not about accidents, but about crafty attacks… systems where you can create such are not huge by today's standards. Big, but not huge.

A local root kernel vulnerability

fenncruz — Tue, 20 Jul 2021 20:20:08 +0000

No catchy name? Or a website? Clearly it can't be that serious if it hasn't been branded.

A local root kernel vulnerability

tlamp — Tue, 20 Jul 2021 20:01:15 +0000

Correction: The commit predates the advisory e-mail (duh, sorry), but it should've added a proper summary and an honest rationale.

Only because it was disclosed properly, see the timeline of the advisory:

========================================================================
Timeline
========================================================================

2021-06-09: We sent our advisories for CVE-2021-33909 and CVE-2021-33910
to Red Hat Product Security (the two vulnerabilities are closely related
and the systemd-security mailing list is hosted by Red Hat).

2021-07-06: We sent our advisories, and Red Hat sent the patches they
wrote, to the linux-distros@openwall mailing list.

2021-07-13: We sent our advisory for CVE-2021-33909, and Red Hat sent
the patch they wrote, to the security@kernel mailing list.

2021-07-20: Coordinated Release Date (12:00 PM UTC).

A local root kernel vulnerability

rgmoore — Tue, 20 Jul 2021 17:21:08 +0000

It's very hard to draw a line between "regular bugs" and "bugs with security implications".

Yes and no. It's true that it's difficult to exclude security implications from "regular bugs"; there's always a possibility a sufficiently clever attacker could find a way to exploit them. But it would be good to come right out and say it when there's a known exploit. I understand the kernel people are worried that mentioning known exploits for some bugs would give people a false sense of security about other ones, but I think that's a highly questionable argument. If you're fixing a known exploit, let people know!

A local root kernel vulnerability

darwi — Tue, 20 Jul 2021 17:08:26 +0000

Correction: The commit predates the advisory e-mail (duh, sorry), but it should've added a proper summary and an honest rationale.

A local root kernel vulnerability

darwi — Tue, 20 Jul 2021 17:01:34 +0000

Fix all the bugs, sure. But don’t intentionally deteriorate the commit log of critical security fixes to hide their main rationale….

Compare the advisory text against the commit log. Whom are we kidding? There should’ve been, at least, a “Link: ” tag in the commit log pointing to the advisory. But no, let’s hide our tracks instead….

A local root kernel vulnerability

ccezar — Tue, 20 Jul 2021 16:50:24 +0000

Well, the total path length exceeding 1GB is not, how to say, normal thing.

A local root kernel vulnerability

bpearlmutter — Tue, 20 Jul 2021 16:11:02 +0000

It's very hard to draw a line between "regular bugs" and "bugs with security implications". Very often, bugs that were thought to not have security implications turn out to be exploitable. It's also not a very interesting endeavor. So they decided to just punt on it: fix all the bugs, and let others decide which to back-port.

Commit messages

proski — Tue, 20 Jul 2021 15:41:42 +0000

Do you have a specific suggestion how to handle such issues better? It would be interesting to explore alternatives.

A local root kernel vulnerability

darwi — Tue, 20 Jul 2021 15:18:50 +0000

It is really sad that, in this day and age, linux kernel security fixes commit logs are still intentionally written to "hide things under the rug."

A local root kernel vulnerability

rahulsundaram — Tue, 20 Jul 2021 15:12:03 +0000

It would be nice if the Linux kernel developers transparently communicate in their commit messages if the commit was intended to resolve a known security issue.