New Linux udisks flaw lets attackers get root on major Linux distros

Post by aidenn0 » Mon, Jun 23, 2025, 4:40 PM UTC

tux1968 wrote: post #142

0xbadcafebee wrote: post #117

Awww. I was just about to gloat about Slackware avoiding another round of security holes due to its long avoidance of PAM, but it got introduced in 2020. :-( It looks like some software projects are now entirely reliant upon PAM for authentication and don't support shadow passwords anymore. What a travesty. It's sort of like what happened with Systemd, where so many apps now entirely depend on Systemd, you can't run…

> reliant upon PAM for authentication and don't support shadow passwords PAM supports a shadow password file as its default configuration. Did you mean something else?

Post by prmoustache » Mon, Jun 23, 2025, 5:15 PM UTC

arbll wrote: post #70

sneak wrote: post #6

Earlier quoted context omitted.

Local root privilege escalation is mostly irrelevant these days. It’s only useful as part of an exploit chain, really. It’s not like shell servers are still around.

this type of exploits are goldmines for attackers, it means they have a window of a few month to years to turn any basic access into root. It doesn't have to be a super complex exploit chain, anyone running wordpress botnets it going to add this to their arsenal

Post by hinkley » Mon, Jun 23, 2025, 5:21 PM UTC

PhilipRoman wrote: post #57

Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…

Post by jowea » Mon, Jun 23, 2025, 5:29 PM UTC

Asooka wrote: post #118

bapak wrote: post #63

Earlier quoted context omitted.

It's incredible to me that sudo has that many LoC. I'd assume it would just ask the OS to execute something without restrictions, not have any logic to do so itself.

There is no such API on Linux, it is accomplished by sudo having the setuid bit set, which instructs the kernel to start it as root regardless of the current user. It's probably one of the worst legacy designs still in use - if any binary has setuid set, it runs as root, no questions asked. Conversely, you also have no way of elevating privileges for a running binary. This really should have been solved decades ago w…

Post by vbezhenar » Mon, Jun 23, 2025, 5:34 PM UTC

kayodelycaon wrote: post #156

SoftTalker wrote: post #126

Earlier quoted context omitted.

> if any binary has setuid set, it runs as root More precisely, it runs as the file owner. Which is often root.

For anyone thinking this is unnecessarily pedantic, it’s not. I didn’t exactly know what setuid did. I learned something today. :)