Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bleepingcomputer.com

Post reply on HN
Print view View original

131–140 of 287 posts

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

#131

Post by capitainenemo »

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…

devuan also uses a stub fake libsystemd but it really is just a stub to avoid broken calls.

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

#132

Post by o11c »

hedora wrote: post #102
hansmayer wrote: post #85

Earlier quoted context omitted.

IPC ?

The GP doesn't understand the vulnerability: https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt Instead of using something standard like environment variables, pam has a special "pam_env" that contains facts about the user session that it apparently trusts. Users can override pam_env settings by writing to hidden file in ~. So, this exploit chain is more accurately described as "yet another example of utili…

If they mutated the real environment it could be even worse, since they're still privileged code and there are all sorts of environment variables that libraries read at runtime using `secure_getenv`.

I finally understand why they're trying to deprecate `pam_env`, despite its incredible utility. For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.

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

#133

Post by jonathanstrange »

faceplanted wrote: post #127
johnisgood wrote: post #121

Earlier quoted context omitted.

Do they not think that the switching is premature? I am pretty sure the Rust version has a lot of logic bugs that not have yet been found.

> I am pretty sure the Rust version has a lot of logic bugs What makes you say that? I'm not trying to be argumentative, I'm genuinely interested.

Whenever a complex system is rewritten, there are a lot of bugs and regressions in it.

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

#134

Post by Sunspark »

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…

Make BSD great again!

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

#135

Post by BirAdam »

icar wrote: post #56

Was Arch ever affected?

As vanilla Arch is sort of a meta-distro, it would largely depend upon what the user chose to install and use. For any one of the many spins of Arch, maybe? But one would need to audit each individually.

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

#136

Post by quotemstr »

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…

Yet people use container based isolation all the time in practice and the sky doesn't fall.

Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that.

I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care about local privilege escalation.

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

#137

Post by IlikeKitties »

mathverse wrote: post #128
IlikeKitties wrote: post #83

Earlier quoted context omitted.

Factually wrong from that very site > grsecurity® is the only drop-in Linux kernel replacement offering high-performance, state-of-the-art exploit prevention against both known and unknown threats. While secureblue is a full desktop distro (not just a kernel) that integrates key grapheneos hardening tools like their hardened malloc and forks of their hardened chromium and works with flatpak as a base for hardened app…

Yes grsecurity offers actual hardening instead of touting snakeoil.

You are literally saying that hardening the kernel is the same as having the desktop environment hardened and a basis for app isolation. And to add a cherry on top of that both secureblue and kicksecure use almost all the same hardening additions to the linux kernel as grsecurity.

You do not understand what you are talking about because if you did you'd be embarrassed for how braindead your response is.

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

#138

Post by quotemstr »

saagarjha wrote: post #64
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.

Asking the OS to do something without restrictions is not very difficult; sudo does that by virtue of its existence (it's setuid). The extra code is deciding when not to do that.

The problem isn't even setuid exactly but the size of the TCB. Setuid encourages a design in which tons of stuff that doesn't need to run as root runs as root anyway just because it's part of the same binary that needs elevated privileges. It's a footgun, but one can handle even a footgun safely if you practice trigger discipline and assume every gun is loaded.

Sudo (and other setuid programs) could in principle use privilege separation to punt everything not absolutely essential to an unprivileged context and thereby reduce the size of the TCB.

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

#139

Post by pxeger1 »

quotemstr wrote: post #136
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…

Yet people use container based isolation all the time in practice and the sky doesn't fall. Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that. I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care…

Wouldn't Android's kernel have most of the hardening steps / disabled features described in GP's comment?
Post reply on HN