15 ms·
New Linux udisks flaw lets attackers get root on major Linux distros
- hbogert 1y agoAs someone who has been using linux quite happily on the desktop for more than 20 years now, I have to say it remains an eternal experiment, feature wise as well as security wise.
- stavros 1y agoIf you think Linux is an experiment, you should see the other OSes.
- khurs 1y agoIncluding Openbsd?
- ahofmann 1y agoI'm pretty sure, that the BSD family is pretty mature and secure. Linux is just good enough for most people.
- deleted 1y ago[deleted]
- charcircuit 1y ago>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.
- NexRebular 1y ago> They are still missing something like capability based security ...like Capsicum? https://wiki.freebsd.org/Capsicum https://wiki.freebsd.org/Capsicum
- charcircuit 1y agoNo, 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.
- NexRebular 1y agoSo the capability-based security framework is not missing unlike your original statement?
- charcircuit 1y agoMy 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.
- 8fingerlouie 1y agoYou can use Jails and limit access to hardware resources for each jail. Still not as dynamic, but will get the job done.
- charcircuit 1y agoSure, but this is not done automatically for the user.
- bee_rider 1y agoFor the types of computers BSD is typically run on, just unplug the webcam.
- wahern 1y agoFreeBSD literally has Capsicum: https://en.wikipedia.org/wiki/Capsicum_(Unix) https://en.wikipedia.org/wiki/Capsicum_(Unix) That might be the most pure capability system out of all of them, though it's not something that works without application modification (yet). Android and iOS applications can automatically work with the native capability framework because they rely on higher-level SDK APIs. But AFAIU those capability systems are very coarse-grained, in the sense that it's difficult leverage the capability system internally within a single application. And keeping lower-level APIs (e.g. for C and POSIX filesystem I/O) nominally working (if at all) requires some impure hacks. All of which makes them very similar to FreeBSD Jails or Linux containers in that respect. I wouldn't consider any of these systems "secure", though, as a practical matter. In terms of preventing a breakout, I'd trust an application on OpenBSD with strict pledge and unveil limits, or a Linux process in a classic seccomp sandbox (i.e. only read, write, and exit syscalls), more than any of those other systems. Maybe Capsicum, too, but I'm not familiar enough with the implementation to know how well it limits kernel code surface area. But any application that can poke at (directly or indirectly) complicated hardware, like the GPU, is highly problematic unless there are proofs of correctness for any series of inputs that can be sent by the process (which I don't think is the case).
- resource_waste 1y agoiOS so so insecure that thousands of people have been hacked and at least 1 person was killed. The last place in security is iOS.
- o11c 1y agoIMO, 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.
- 8fingerlouie 1y agoA big part of the difference is that the BSDs are designed by a governing committee. They usually don't have 15 different solutions for the same problem, but instead 2-3 solutions that work well. Take filesystems, the official filesystems are UFS(1/2) and ZFS. They have GEOM as LVM and LUKS and more. That being said, the majority of money and development goes into Linux, which by itself may make it a better system (eventually). Edit: Of course UFS is not deprecated.
- assimpleaspossi 1y agoUFS is not deprecated on FreeBSD.
- hxorr 1y agoI believe it is the default on netBSD
- graemep 1y ago> A big part of the difference is that the BSDs are designed by a governing committee. They usually don't have 15 different solutions for the same problem, but instead 2-3 solutions that work well. The right comparison is not between a particular BSD and Linux, its between a particular BSD and a Linux distro.
- jeltz 1y agoI feel the BSDs are much more different from each other than the average Linux distros are.
- graemep 1y agoAverage/most popular distros, maybe. The full range of distros are very different from each other. Consider Void, Alpine, Gentoo, Chimera, NixOS..... Different C libraries, init systems, different default command line utilities....
- NexRebular 1y ago> I'm pretty sure, that the BSD family is pretty mature and secure. Not to mention illumos-based systems too.
- johannes1234321 1y agoI ran Open Solaris for a while on my Laptop and it's quite nice. However the lack of support by practically any software vendor made many things a pain. Since then even more stuff went to the Web, but I really I doubt Illumos got any extra traction.
- NexRebular 1y agoMost of our server infrastructure runs on illumos at $work. SmartOS/Triton handles our "cloud" and OmniOS runs our storage. The linux monoculture problem luckily can still be handled with zones and bhyve, and I do trust illumos developers' competence to deliver good quality secure software a lot more than linux developers' as well. Now if FreeBSD (or indeed illumos) would get CUDA-support we could stop using linux for GPU nodes too.
- throw0101b 1y ago> Now if FreeBSD (or indeed illumos) would get CUDA-support we could stop using linux for GPU nodes too. Could you not run Linux CUDA binaries under FreeBSD's Linuxulator?
- NexRebular 1y agoIt is possible, yes, but I would prefer to have full linux-free support for production use. There is on-going work for FreeBSD Cuda, though[0]. Just have to wait and see. [0] https://www.freebsd.org/status/report-2024-04-2024-06/#_partnerships_and_research https://www.freebsd.org/status/report-2024-04-2024-06/#_part...
- bee_rider 1y agoBSD doesn’t count, everybody agrees it is the best OS they aren’t using.
- pandemic_region 1y ago> I have to say it remains an eternal experiment You just defined 'life' in general.
- subscribed 1y agoThat's certainly an interesting standpoint. I use both privately and professionally and while I accept that security-wise (even with selinux) they feel lacking, feature-wise they far exceed Windows I use as my other is except in gaming experience. I wish I had something like GrapheneOS on desktops (yes I know about Qubes)
- throawayonthe 1y agosame! qubes is probably the actual solution for now, but i've seen some grapheneos people work on https://secureblue.dev/ https://secureblue.dev/ and that seems a lot more "normal"
- udev4096 1y agoI have been meaning to try out secureblue and hopefully even run it on production VMs in proxmox. Is it stable yet?
- IlikeKitties 1y ago> I wish I had something like GrapheneOS on desktops (yes I know about Qubes) SecureBlue and Kicksecure are the closest equivalents.
- mathverse 1y agoNo the closest alternative is https://grsecurity.net/ https://grsecurity.net/
- IlikeKitties 1y agoFactually 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 application deployment. grsecurity does literally none of that.
- sneak 1y agoLocal 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.
- magicalhippo 1y agoAn exploit chain, like combining it with the PAM issue they mentioned in the very same article, affecting Fedora.
- TheDong 1y agoThe article was about two issues that combine to make a single local-privilege-escalation, so the PAM thing isn't a separate exploit chain, it's just part of getting local root in this vulnerability. What the parent poster meant is that you first need a way to run arbitrary code before local privilege escalation matters, so the exploit chain has to include _something_ that gets you local code execution. I tend to agree with the parent poster, for most modern single-user linux devices, local privilege escalation means almost nothing. Like, I'm the only user on my laptop. If you get arbitrary code execution as my user, you can log my keystrokes, steal my passwords and browser sessions, steal my bitcoin wallet, and persist reasonably well.... and once you've stolen my password via say keylogging me typing `sudo`, you now have root too. If you have a local privilege escalation too, you still get my passwords, bitcoin wallet, etc, and also uh... you can persist yourself better by injecting malware into sshd or something or modifying my package manager? idk, seems like it's about the same.
- simoncion 1y ago> ...for most modern single-user linux devices, local privilege escalation means almost nothing. I haven't actually looked at the numbers, but I strongly suspect that it's true that the overwhelming majority of single-user Linux devices out there are Android devices. If that's true, then it's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root would actually be a significant gain in access.
- deleted 1y ago[deleted]
- devnullbrain 1y ago>20 years ago So while Windows was letting everyone be root?
- amelius 1y agoWhat especially feels like an experiment is container technology.
- coderatlarge 1y agohow much harder is container escaping compared to vm escaping? i understand that containers are not truly meant to be security boundaries but they are often thought of and even used as such.
- fc417fc802 1y ago> how much harder is container escaping compared to vm escaping? The answer heavily depends on your configuration. Unprivileged with a spartan syscall filter and a security profile is very different than privileged with the GPU bindmounted in (the latter amounts to a chroot and a separate user account).
- tetha 1y agoHence if I ever get money for an infrastructure pentest, I want to include a scenario that scares me a bit: The hijacked application server. The pentesters give me a container with whatever tooling they want and a reverse shell and that gets deployed in the dev-infrastructure, once privileged and once unprivileged, both with a few secrets an application server would have. I'd just reuse a deployment config from some job. And then have at it. And yes, this will most likely be a mess.
- arbll 1y agoSituational but if you're in default configurations it's comparable. Both will need some form of unknown vuln. It boils down to wether you trust more the linux namespacing logic and container runtime glue or the hypervisor logic.
- franga2000 1y agoRe:"Eternal experiment"... have you seen Windows 11? Or even 10? The devs can't keep their hands off of the thing, changing, breaking and fixing every component every few months.
- Geezus_42 1y agoAdding ADs to every possible surface, finding new ways to obfuscate built-in spyware
- bee_rider 1y agoI don’t think we need to “whatabout” Windows. I don’t think anyone would say they are trying too many experiments… actually, Windows feels like it was mostly made by overworked folks doing the bare minimum to not get fired. No time for experiments or caring.
- phendrenad2 1y agoThis is the attitude that holds Linux back the most. Quick, what is the #1 priority of Linux? "Being better than Windows". Not being good, great, or even amazing? No, as long as it's 0.0001% better than Windows, it can be awful! And people will say "Yeah, but it is amazing". Then why do so many people feel the need to defend it in terms of _being better than Windows_? Clearly they prioritize the perception of being better than Windows over being actually good, because otherwise they would defend it by pointing out how good it is. Are they all just weirdos, or have they subconsciously picked up on the real but unwritten culture of Linux?
- yusina 1y agoSoftware is rarely "done", so is quite naturally always an evolving experiment of sorts.
- jpnc 1y agoThat goes for all (active) software really. Otherwise people call it obsolete or abandoned.
- 0points 1y agoWe're talking about a local privilege escalation here. That assumes: 1) Attacker already have an account on the system 2) The app `udisks` is installed on the system. Everyone is fighting the same battle and it's a good thing. It is happening because the rest of the system is hard enough to attack these days. This is true for all major OS:es. Only fanboys bend reality to make this into a good-vs-bad argument.
- resource_waste 1y agoLet us not pretend other OS are flawless as well. Microsoft is constantly patching and Apple has been the source of so many hacks that thousands of VIPs were affected and a person was murdered.
- danparsonson 1y agoWhat a weird comment - if Apple software had less exploits then the murder would have been averted? And those 'VIPs', whoever they are - would it be less significant if there were normies? I sincerely hope none of my coding mistakes ever causes a VIP to be murdered.
- deleted 1y ago[deleted]
- teddyh 1y agoFixed two weeks ago (in Debian at least).
- simoncion 1y agoYup. And it was never a problem in Gentoo.
- aesh2Xa1 1y agoIt's there in Gentoo, too. https://bugs.gentoo.org/buglist.cgi?quicksearch=udisks https://bugs.gentoo.org/buglist.cgi?quicksearch=udisks
- simoncion 1y agoThe other required component of the exploit isn't present without operator intervention, so (as I said) it's not a problem in Gentoo: <https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-6018#c1 https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-6018#c1>.
- udev4096 1y agoIt's pretty old and only affects openSUSE, the title is extremely misleading
- aspenmayer 1y ago> The Qualys Threat Research Unit (TRU), which discovered and reported both flaws, has also developed proof-of-concept exploits and successfully targeted CVE-2025-6019 to get root privileges on Ubuntu, Debian, Fedora, and openSUSE Leap 15 systems. https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt
- shakna 1y ago- openSUSE Leap 15 (Current LTS) - SUSE Linux Enterprise 15 (Current LTS) - Debian 12 (Current LTS) - Ubuntu 24.04 (Current LTS) ... Were you thinking about a different bug...?
- ethan_smith 1y agoThe vulnerability affects multiple major distributions including Ubuntu, Fedora, and Debian (though some have already patched it), not just openSUSE as claimed.
- charcircuit 1y agoAnother case of suid causing LPE. When will distros learn that suid needs to be removed or disabled if they want security?
- pona-a 1y agoudisks, 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 CVEs.
- bapak 1y agoIt'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.
- saagarjha 1y agoAsking 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.
- pinoy420 1y ago[dead]
- quotemstr 1y agoThe 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.
- rcxdude 1y agosudo has a lot of machinery for representing complex policies which involve partial access to elevated (or just different) permissions, and with more conditions than just a correct password for the requesting user. The kernel itself just sees a binary running as root which may drop some of those permissions before starting another process. (And this isn't even the most arcane part of linux userland authorization and authentication. PAM is by far the scariest bit, very few people understand it and the underlying architecture is kinda insane)
- icar 1y agoWas Arch ever affected?
- deleted 1y ago[deleted]
- BirAdam 1y agoAs 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.
- jillesvangurp 1y agoBriefly maybe, until somebody fixed it and then everyone updated and moved on with their lives. That kind of is the point of rolling distributions.
- PhilipRoman 1y agoLocal 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 hide most of the kernel. But you really have to know what you're doing and proper security hardening will break a lot of software. To get a basic level of security, you have to disable anything with the letters "BPF", hide all virtual filesystems like /proc, /sys, disable io_uring and remove every CONFIG_* you see until something stops working. Some subsystems seem more vulnerable than others (ironically netfilter seems to be a steady source of vulnerabilities).
- pinoy420 1y agoGiven this. Why is every linux device not rooted then.
- hnlmorg 1y agoBecause GP is talking about theoretical vectors of attack in highly secure environments. Whereas you are now discussing why hackers don’t target devices with zero-financial gain. Also just because syscall A might be vulnerable to a particular type of attack, it doesn’t mean that service B uses that syscall, let alone calls it in a way that can be exploited.
- duxup 1y agoI think in the land of people with ill intent to exploit such things they have more potential targets and security vulnerabilities than they can spend time exploiting. A given vulnerability may be terrible, but it might not coincide with something worth bothering with for a given person with ill intent. There's a factor of human choice / payoff at play.
- tptacek 1y agoI 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.
- belorn 1y agoCould someone describe what 'allow_active' privileges is on Linux?
- rcxdude 1y agoIt's not something that means anything to the kernel, it's a concept in polkit and the various associated userland authorization frameworks which basically means 'things a user currently sat in front of the machine and logged on should be able to do', which includes things like mounting USB drives (but not in arbitrary places and with arbitrary options) and the like.
- yrro 1y agohttps://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html https://www.freedesktop.org/software/polkit/docs/latest/polk...
- mkj 1y agoAnother case of environment variables causing LPE. Wonder if we'll ever end up with something more robust for passing details between processes than parsing ambient settings from strings.
- hansmayer 1y agoIPC ?
- hedora 1y agoThe GP doesn't understand the vulnerability: https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt 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 utilities inventing new, obscure configuration mechanisms for security-critical settings, allowing policy flaws to remain undetected for a long time". Running security configuration options through a special snowflake IPC mechanism (instead of keeping them in a file where they could actually be inspected by humans) would only make things worse.
- mkj 1y agoOk yeah, I had actually misread what the vars were. But it's the same kind of problem as general environment vars - rather than just a name, maybe it needs metadata of where it came from. To be clear, I'm talking about the unprivileged to allow_active CVE-2025-6018, not the allow_active to root.
- Piraty 1y agohttps://xeiaso.net/talks/surreal-horror-pam-2021-11-09/ https://xeiaso.net/talks/surreal-horror-pam-2021-11-09/
- o11c 1y agoIf 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.
- 1970-01-01 1y agoFlaw, bug, and security vulnerability are intermixed in the article. This is a mature field. The word choice should be consistent, and it stinks of poor quality when someone chooses to treat them as if they are technically interchangeable problems.
- gmac 1y agoI don't think so. A security vulnerability is a kind of bug, and a bug is a kind of flaw. Once you've introduced a problem using the most specific terminology, it's OK to refer to it using less specific terminology. It can help you avoid sounding repetitive. (This reminds me of one of my kids at a very young age. If you said "I like your trousers", she'd reply "they're not trousers, they're jeans". But, of course, jeans are a kind of trousers, and it isn't mandatory to be as specific as possible at all times).
- 1970-01-01 1y agoSoftware bug is just one area in the venn diagram of security vulnerability. Include areas outside of this such as insecure default settings, misconfigurations, major design weaknesses, hardware exploitations, etc. and you see my point.
- 0xbadcafebee 1y agoAwww. 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 a Linux desktop without a "fake Systemd" to make things work. (see: Alpine Linux desktop, Slackware desktop) All of this seems to be due to a kind of creepy crawly takeover of the system components, with new ones designed by enterprise companies and a few highly-opinionated software developers (who work at those companies). They design these components to do a million different things, but they also make them highly coupled and interdependent (which is terrible software design, but standard for enterprise products). This then results in a much more complex system with many more moving parts, and makes breaking it easier. Since these companies hold sway over the most popular Linux distros with the most users, when they make a radical change, everybody else has to adopt it, just like with the browser world. Powerful incumbents exert an unfair (and unhealthy) amount of influence on our environment. If you went back to a distro from 20 years ago, there really should only be a couple components: The X ecosystem (kernel drivers, userland drivers, rendering libraries), a console login program, a tty manager, a wifi manager, and, well... i'm struggling to think of anything else you need [after the system has booted]. Kernel drivers used to make up 90% of the hardware interfaces. Originally you just wrote to a device file for things like sound, printing, etc. It was an extremely simple system and it worked very well. Today you have 80 different daemons all running at the same time in order for the system to work at all. Event buses, policy engines, management frameworks, a couple dozen libraries, and multiple layers of components to do something as simple as run a graphical app in a windowed environment. Is this all necessary? Clearly not, as we did without all this crap 20 years ago. Somebody screwed the pooch on system design. Luckily, it's Linux, so nobody is forcing us to use all this shit. We can just start over with a new, much simpler system (and try hard as hell to avoid second system effect)
- capitainenemo 1y agodevuan also uses a stub fake libsystemd but it really is just a stub to avoid broken calls.
- b0a04gl 1y ago[dead]
- neuroelectron 1y agoGolden opportunity for bitcoin miners on AWS.
- fitsumbelay 1y agoHello, I need some help understanding how the combined exploits affect users of not-SUSE distros. Thanks
- KingLancelot 1y ago[dead]
- baobun 1y agoTangent(?) 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.
- Arnavion 1y agoIt 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`