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

201–210 of 287 posts

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

#201

Post by tptacek »

SEJeff wrote: post #200
tptacek wrote: post #189

Earlier quoted context omitted.

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

Thomas, what are your thoughts on micro-vms such as kata containers? You can use them as a backend for docker in place of runc. I'm sure you're well aware, but for the readers, they are isolated with a CPU's VT instructions which are built to isolate VMS. I still think "containers don't contain" in a very Dan Walsh boston accent, but this seems like a respectable start. https://katacontainers.io

I have no strong opinion other than that untrusting cotenants shouldn't directly share a kernel.

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

#202

Post by NexRebular »

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.

I've even seen namespaces used for hiding malicious software in Ubuntu systems too.

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

#203

Post by rob_c »

Dylan16807 wrote: post #181
uncircle wrote: post #123

Earlier quoted context omitted.

https://xkcd.com/1200/

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

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...

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

#204

Post by rob_c »

crest wrote: post #146
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…

That's a cheap cop out.

You've worked in security theatre before then ;)

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

#205

Post by karlgkk »

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

> memory errors with no viable exploit path

i dont appreciate putting "vulns" in scare quotes, if that was your intent

swiss cheese theory. all it takes is someone changing a component that allows that vulnerability to be chained into an exploit, which has happened many times.

these should be tracked, and in fact, it's very helpful to assign cves to them

but yeah, raw numbers is less useful. in fact, cves as a "is it secure or not" metric are pretty rough. it makes it easier to convince vendors to keep their software up to date, though...

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

#206

Post by o11c »

charcircuit wrote: post #34
ahofmann wrote: post #11

Earlier quoted context omitted.

I'm pretty sure, that the BSD family is pretty mature and secure. Linux is just good enough for most people.

>is pretty mature and secure They are still missing something like capability based security like iOS and Android have where apps have to be granted access to use things like files or the camera. It may have been considered secure a couple decades ago, but they have fallen behind the competiton.

IMO, the real problem with trying to enforce capability-based systems on desktop/server environments is the correct API isn't implemented. `capabilities(7)` is only a tiny subset of `credentials(7)`, `PR_SET_NO_NEW_PRIVS` is an abomination, `SCM_RIGHTS` has warts, and `close_range` is fundamentally braindead.

We need at least the following sets: effective, permitted, bounding (per escalation method?), and the ability to make a copy of all of the preceding to automatically apply to a child (or to ourselves if we request an atomic change). Linux's `inheritable` set is just confusing, and confusion means people will use it wrong. At least we aren't Windows.

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

#207

Post by anthk »

graemep wrote: post #148
anthk wrote: post #129

Earlier quoted context omitted.

That's nothing. Alpine can run Glibc binaries with compat libraries. Try running a FreeBSD binary under OpenBSD.

But only with compat libraries. Similarly FreeBSD can provide Linux compatility. Wine lets you run Windows binaries on multiple OSes.

You can't run neither FreeBSD nor NetBSD binaries under OpenBSD.

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

#208

Post by quotemstr »

antoinealb wrote: post #165
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…

Android delegated some security features to a different kernel called Trusty that is separated from the main Linux kernel using virtualisation. That kernel runs high value security services. https://source.android.com/docs/security/features/trusty

Yes, but that's not the main load-bearing security part of the system. Trusty doesn't isolate apps from each other. It doesn't isolate work profiles from user profiles. Regular SELinux-augmented thoughtfully-used uid- and process-isolation does that.

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

#209

Post by Dylan16807 »

rob_c wrote: post #196
Dylan16807 wrote: post #192

Earlier quoted context omitted.

Relax, someone else already explained it without shouting.

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.

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

#210

Post by Dylan16807 »

rob_c wrote: post #203
Dylan16807 wrote: post #181

Earlier quoted context omitted.

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

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 very unlikely the urge for admins to patch this is directed at you.

Post reply on HN