upvote
Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority.

https://ubuntu.com/security/cves/about#priority

> Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.

reply
Strange that it's not classified as "high", which specifically includes "local root privilege escalations".

> High: A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss.

reply
It is high now, someone at canonical is paying attention it seems
reply
if your model is that linux is just about single-user desktops, this local exploit isn't too bad. or if your model is nothing but DB servers or the like.

mystifying to me that shared, multi-user machines are not thought of. for instance, I administer a system with 27k users - people who can login. even if only 1/10,000 of them are curious/malicious/compromised, we (Canadian national research HPC systems) are at risk. yes, this is somewhat uncommon these days, when shell access is not the norm.

but consider the very common sort of shared hosting environment: they typically provide something like plesk to interface to shared machines with no particular isolation. can you (as a website owner or 0wner) convince wordpress/etc to drop and execute a script? yep.

reply
Not to bad? So we just threat linux overall as a single user system or what?
reply
> if your model is that linux is just about single-user desktops, this local exploit isn't too bad.

For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.

reply
Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.
reply
Yubikeys are also surprisingly annoying when setup for the as well. A working developer just needs sudo a lot.

Realistically a "sudo button" would be handy, on the keyboard, with a display to show a confirmation pin for the request (probably also needs a deny button so you can try and identify weird ones).

reply
hmm have i missed anything?
reply
Any program on your computer can just run "sudo" to escalate itself.
reply
Local access is a bit of a misnomer though, a vulnerable website can be tricked into running a script
reply
Ubuntu seems to have updated the page to say that it's a high priority now.
reply
deleted
reply
it's not like this couldn't be chained with some other exploit to get remote access to get remote root access which seems like a bit of an issue
reply
deleted
reply
It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).
reply
Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel?

This stance doesn't seem sustainable any more to me.

reply
The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even worse though and I'm misremembering.

The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvisor users are not impacted by this CVE. Seccomp also kills this CVE.

reply
How about SELinux, like on Android?
reply
selinux on enforcement mode did not mitigate the exploit when I tested today on fedora coreos :(
reply
To even get the su binary on Android you have to patch the OS. So this exploit can't work on Android. Because there is no su binary to target.

Update: Just tried it on Termux and as expected even creating an AF_ALG socket requires root access.

reply
The specific exploit payload for the POC relies on a su binary. The vuln is ambivalent and other non-su paths will exist.
reply
I assume that wouldn't help here but I could easily be wrong. (Assuming if you're asking if SELinux would block this exploit).
reply
I'm schocked that ubuntu is aware of this and the prv lts is not patched yet :|

wtf

reply
RedHat has also changed it to "Important severity" and "Affected" now.
reply
I thought that. surely people are going crazy right now owning anything with an our of date Wordpress exposed.
reply
Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.
reply
That was fixed, it’s now marked high.
reply
deleted
reply