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

221–230 of 287 posts

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

#221

Post by PhilipRoman »

DCKing wrote: post #213
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…

> they should really look at kernel CVE database When quoting kernel CVEs as evidence as signs of insecurity, especially so seemingly authoritatively, please make sure you're informed about how what Linux kernel CVEs mean. A CVE (for any product) does not automatically mean there is actually a vulnerability there or even if one is exploitable unless explicitly noted (in the CVE or credibly by someone else). Proof of…

You're right. I review each one carefully, so here I mean only the real ones. It's still a massive amount of vulnerabilities, even after excluding obscure drivers or features that aren't used on headless systems.

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

#222

Post by baobun »

Tangent(?) on the SUSE PAM part: I was always tripped up by openSUSE default sudo behavior compared to other dists. Unless run with root, it will prompt you for the password of the target user, not your current one, even when current is allowed by sudoers policy.

So 'sudo -u foo bash' will prompt for the password of user foo, 'sudo bash' will prompt for the root password.

Haven't looked closer on how deep this custom configuration goes but would be nice to not have to carry around actual root password for sudo.

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

#223

Post by 0xbadcafebee »

Sunspark wrote: post #134
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!

Well, damn... that's not a bad idea. It's only been 20 years since I last tried FreeBSD. Anything changed?

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

#224

Post by shakna »

Dylan16807 wrote: post #210
rob_c wrote: post #203

Earlier quoted context omitted.

And your pulse audio service is running as which user now? This is a local exploit but for any system supporting the mentioned combination of services, aka a lot of them, including the RHEL derivatives and likely Ubuntu. https://almalinux.org/blog/2025-06-18-test-patches-for-cve-2...

> And your pulse audio service is running as which user now? I'm not sure, I appear to be running pipewire. But assuming it's not my own account: not a user that will initiate an attack. A user account that allows logins or runs external servers would have to get compromised first, and at that point it can use the exploit directly with no need to touch pulseaudio. If there's only one directory in your /home, it's ver…

Pipewire runs under the pipewire user, managed by systemd or OpenRC. Which means any of their managed processes can start a new pipewire user process.

A local priv-sec is one exploit [0] away from a remote one.

[0] https://www.bleepingcomputer.com/news/security/hackers-explo...

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

#225

Post by galangalalgol »

immibis wrote: post #186
galangalalgol wrote: post #167

Earlier quoted context omitted.

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.

Separate processes running the same shared instructions. If you compromise and modify those shared instructions, the othe container runs instructions of your choosing.

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

#226

Post by eyberg »

zamalek wrote: post #166
quotemstr wrote: post #136

Earlier quoted context omitted.

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…

If you weren't aware, containers aren't a security boundary. Things like bubblewrap are.

bubblewrap is actually worse - there are known escapes in there that haven't been fixed for years

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

#227

Post by rob_c »

Dylan16807 wrote: post #209
rob_c wrote: post #196

Earlier quoted context omitted.

At the time they hadn't and I'm fed up of the jumping to conclusions that env vars are the cause of any security issue. This is blaming poor code from poor devs on expert features from UNIX all to often. Worrying when said person has authored a widely used security product(!). This is a bad trend in the industry that needs to stop.

> At the time they hadn't Their comment was before yours.

if that's the comment you mean, it also misses the point

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

#228

Post by kbolino »

galangalalgol wrote: post #225
immibis wrote: post #186

Earlier quoted context omitted.

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.

Separate processes running the same shared instructions. If you compromise and modify those shared instructions, the othe container runs instructions of your choosing.

Layers are COW so one container modifying a layer has no effect on other containers started from the same image. Of course, preexisting vulnerabilities will remain but they'd have to be separately exploited in each container.

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

#229

Post by Arnavion »

baobun wrote: post #222

Tangent(?) on the SUSE PAM part: I was always tripped up by openSUSE default sudo behavior compared to other dists. Unless run with root, it will prompt you for the password of the target user, not your current one, even when current is allowed by sudoers policy. So 'sudo -u foo bash' will prompt for the password of user foo, 'sudo bash' will prompt for the root password. Haven't looked closer on how deep this custom…

It is still the default but it's also trivial to change, so you don't have to "carry around actual root password" for any longer than it takes to create a dropin in /etc/sudoers.d/ with `Defaults !targetpw; %wheel ALL=(ALL) ALL`

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

#230

Post by ethan_smith »

udev4096 wrote: post #22

It's pretty old and only affects openSUSE, the title is extremely misleading

The vulnerability affects multiple major distributions including Ubuntu, Fedora, and Debian (though some have already patched it), not just openSUSE as claimed.
Post reply on HN