New Linux udisks flaw lets attackers get root on major Linux distros • Hacker News Board

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

#181

Post by Dylan16807 » Mon, Jun 23, 2025, 4:17 PM UTC

uncircle wrote: post #123

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…

https://xkcd.com/1200/

Not really relevant, the threat being discussed is for multi-user systems.

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

#182

Post by tgbugs » Mon, Jun 23, 2025, 4:19 PM UTC

pona-a wrote: post #54

udisks, not counting its dependencies, has 265,334 LoC. pmount, in contrast, has 19,978 LoC, or >13x less. sudo, another setuid binary with a lot of policy code, has 210 CVEs / 430.150 kLoC = ~0.5 CVE per kLoC. 57.5% of CVEs have a CVSS >= 7, so 0.5 * 0.575 = 0.2875 CVE7/kLoC. As a back-of-envelope estimate, udisks: 0.2875 CVE7/kLoC * 265.334 kLoC = ~76.28 critical CVEs; pmount: 0.2875 CVE7/kLoC * 19.9780 kLoC = ~5.7…

This is yet another case where my policy of stripping out unnecessary dependencies has paid off. thunar-volman and kde solid both pull in udisks by default but back in 2017 I started maintaining a fork of the default Gentoo ebuild to eliminate the dependency on udisks. The thunar-volman case is a great example of why Gentoo use flags are useful no only for customizing a system but for security by making it easier to reduce the attack surface by disabling features that upstreams leave enabled by default.

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

#183

Post by ranger_danger » Mon, Jun 23, 2025, 4:20 PM UTC

holowoodman wrote: post #178

stefan_ wrote: post #168

Earlier quoted context omitted.

Ironically Ubuntu 24 now blocks users from accessing namespaces because that kernel interface had a bunch of local privilege escalations, breaking programs that want to use them for isolation.

For the last 10 years or so, namespaces in Linux were the source of the absolute hightest number of local privilege escalations and sometimes even arbitrary code executions in kernel space. Building a kernel without user namespace support has been goto-advice for multiuser systems for almost as long. Ubuntu is just late to the game because they mostly have server or single-user-desktop customers.

Seems ironic considering namespaces are highly utilized for isolation/security purposes.

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

#184

Post by rcxdude » Mon, Jun 23, 2025, 4:25 PM UTC

NicolaiS wrote: post #170

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…

After the Linux Foundation became a CNA (CVE Numbering Authority), it started issuing CVEs for a broad range of "vulns", such as local denial-of-service, memory errors with no viable exploit path, and logic flaws lacking meaningful security implications. Looking at the raw number of CVEs is not very meaningful

Indeed. They issue a CVE for every bugfix, because it's long been the position of the linux maintainers that there's no meaningful distinction between a security bug and a regular bug.

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

#185

Post by charcircuit » Mon, Jun 23, 2025, 4:29 PM UTC

NexRebular wrote: post #53

charcircuit wrote: post #45

Earlier quoted context omitted.

No, that requires explicit changes by programs to use meaning that malware can ignore it and steal your browser's cookies and take secret photos with your webcam.

So the capability-based security framework is not missing unlike your original statement?

My original statement is about how users have to explicitly give programs access to the files and the webcam before they can use them. This is missing.

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

#186

Post by immibis » Mon, Jun 23, 2025, 4:32 PM UTC

galangalalgol wrote: post #167

quotemstr wrote: post #150

Earlier quoted context omitted.

No. Things like eBPF, strace, and packet filtering are enabled. Android uses SELinux and other facilities to limit the amount of code the kernel will allow to access these features. Big difference from their being compiled out of the kernel entirely as the OP suggests is necessary.

Container isolation can fail at shared libraries in shared layers too can't it? My evil service is based on the same cooltechframework base layer as your safety critical hardware control service and if there is a mistake in the framework...

then it affects each one separately since they are separate processes. The fact they run the same code is irrelevant if the data is separate.

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

#187

Post by immibis » Mon, Jun 23, 2025, 4:33 PM UTC

ranger_danger wrote: post #183

holowoodman wrote: post #178

Earlier quoted context omitted.

For the last 10 years or so, namespaces in Linux were the source of the absolute hightest number of local privilege escalations and sometimes even arbitrary code executions in kernel space. Building a kernel without user namespace support has been goto-advice for multiuser systems for almost as long. Ubuntu is just late to the game because they mostly have server or single-user-desktop customers.

Seems ironic considering namespaces are highly utilized for isolation/security purposes.

I presume they're left enabled for root.

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

#188

Post by stouset » Mon, Jun 23, 2025, 4:35 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…

> anyone still thinks that they can draw a security boundary anywhere with a shared kernel

Containers are everywhere.

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

#189

Post by tptacek » Mon, Jun 23, 2025, 4:37 PM UTC

stouset wrote: post #188

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…

> anyone still thinks that they can draw a security boundary anywhere with a shared kernel Containers are everywhere.

They don't work as reliable security boundaries; they're developer/ops tools.

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

#190

Post by tptacek » Mon, Jun 23, 2025, 4:38 PM UTC

pinoy420 wrote: post #79

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…

Given this. Why is every linux device not rooted then.

I think a majority of systems security people, if asked, would say they assume an attacker with code execution on a Linux system can raise privileges.