Was Arch ever affected?
Briefly maybe, until somebody fixed it and then everyone updated and moved on with their lives. That kind of is the point of rolling distributions.
New Linux udisks flaw lets attackers get root on major Linux distros
151–160 of 287 posts
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#152Earlier quoted context omitted.
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. 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 (e…
I can't help but make the comparison with cryptographic network protocols, where the industry started with a kitchen-sink approach (e.g. pluggable cipher suites in TLS) and ended up moving towards fixed primitives (e.g. Wireguard mostly uses DJB-originated techniques, take them or leave them). The general lesson from that seems to be that a simpler, well-understood, well-tested and mostly static attack surface is bet…
The main strength of WireGuard is that it’s simple. It’s like 10% of the code size of IPSEC.
Less code means less possibility for bugs, and is easier to audit.
In my book, WireGuard perfectly follows the UNIX philosophy of making a simple tool that does exactly one thing and does it well.
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#153Re: New Linux udisks flaw lets attackers get root on major Linux distros
#154Earlier 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.
I’m a pretty big advocate on Rust and while Rust does protect classes of certain kinds of bugs and probably encourages better unit test hygiene and thus higher code quality, it does not protect against logic bugs and all the historical CVEs and thus it’s possible for previous exploits vectors to resurface. Thus it’s not an unreasonable prior to assume there are vulnerabilities lurking.
On the other hand, if the replacement isn’t targeting full sudo feature set and also reducing the amount of code and/or making architectural improvements like keeping most code not running as root, then the blast area of such logic bugs can be reduced.
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#155Earlier quoted context omitted.
Yup. And it was never a problem in Gentoo.
It's there in Gentoo, too. https://bugs.gentoo.org/buglist.cgi?quicksearch=udisks
The 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>.
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#156Earlier quoted context omitted.
There is no such API on Linux, it is accomplished by sudo having the setuid bit set, which instructs the kernel to start it as root regardless of the current user. It's probably one of the worst legacy designs still in use - if any binary has setuid set, it runs as root, no questions asked. Conversely, you also have no way of elevating privileges for a running binary. This really should have been solved decades ago w…
> if any binary has setuid set, it runs as root More precisely, it runs as the file owner. Which is often root.
For anyone thinking this is unnecessarily pedantic, it’s not.
I didn’t exactly know what setuid did. I learned something today. :)
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#157Earlier quoted context omitted.
> A big part of the difference is that the BSDs are designed by a governing committee While I cannot agree nor disagree on the quality of BSDs (haven't used one in 20 years), I find it funny that in this case a design by committee is proof of quality. I guess it's better than design by headless chicken which is how the Linux user-space is developed. Personally, I am a big fan of design by dictatorship, where one guy…
> While I cannot agree nor disagree on the quality of BSDs (haven't used one in 20 years), I find it funny that in this case a design by committee is proof of quality. I don't think "design" is correct word: organized, managed, or ran perhaps. > The FreeBSD Project is run by FreeBSD committers, or developers who have direct commit access to the master Git repository.[1] The FreeBSD Core Team exists to provide directi…
They fill the same position as a BDFL though.
They decide what gets included in the default distribution, they set the goals and provider sponsorships for achieving them.
So yes, board of directors is probably more fitting.
And then of course you have the people with a commit bit. They can essentially work on whatever they like, but inclusion into the main branch is still up to the core team.
There was a huge debate some years ago when Netgate sponsored development/porting of WireGuard to FreeBSD, and the code was of a poor quality, and was ultimately removed from FreeBSD 13.
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#158Local 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 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.
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#159Earlier quoted context omitted.
> It's permissively licensed, unfortunately. Well damn that's a shame. I just hate it when people let others use their work in a way they choose, that happens to be less restrictive than my own personal choices. /s of course.
Worked out for Linux, which remains a largely open, collaborative ecosystem. Meanwhile all the BSDs are good for are as less-good Linuxes that can be shoved into proprietary products. Google is choking out AOSP, which they can do because of Android's "less restrictive" license. Copyleft licenses are demonstrably better for open source projects in the long run. We've had enough time to prove that out now.
That is an extremely cherry-picked example. There are plenty of examples of permissively-licensed software that is very successful, and no evidence that the license choice is why Linux won.
Re: New Linux udisks flaw lets attackers get root on major Linux distros
#160Earlier quoted context omitted.
> 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.
All the rewriters are offended by the truth.