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

101–110 of 287 posts

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

#101

Post by gmac »

1970-01-01 wrote: post #97

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

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

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

#102

Post by hedora »

hansmayer wrote: post #85
mkj wrote: post #82

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

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

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

#103

Post by Xylakant »

scheeseman486 wrote: post #96
stephenr wrote: post #91

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

I think it's pretty reductive to boil down linux' success to the choice of license. There's governance model, development model, institutional inerta, ... - and the linux ecosystem contains tons of permissively licensed pieces of software, some of which massively contributed to its success (the once-default webserver that came with its own permissive license, the APL). Even the kernel includes APL, BSD-2 Clause and MPL'ed code.

To the contrary, GNU Hurd is GPL'ed and is much less successful than the linux kernel.

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

#104

Post by einpoklum »

bapak wrote: post #63
pona-a wrote: post #54

udisks, 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…

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.

When I'm told my code needs to "just" do X, it is usually the case that it needs to do a bunch of other stuff to enable X.

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

#105

Post by salawat »

ikekkdcjkfke wrote: post #90
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.

Why does anything at all need to be executed without restrictions though

Should your calculator ask who you are to compute 2+2? Contrary to popular belief, access control was stapled onto the computation space. There was a time when it was considered an unnecessary extravagance. It only became the night unbuckle mandate that machines give a shit about who you are once we started using computers as the basis of business systems.

Accounts thereafter, ruined everything.

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

#106

Post by bee_rider »

ahofmann wrote: post #11
stavros wrote: post #3

Earlier quoted context omitted.

If you think Linux is an experiment, you should see the other OSes.

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

BSD doesn’t count, everybody agrees it is the best OS they aren’t using.

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

#108

Post by b112 »

commandersaki wrote: post #88
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.

I think it's all the stuff to do with using a shared sudoers across a network of hosts. They could really clean up the language if they removed all of that gunk, as it's not reflective of how sudo is deployed these days.

There's also full sudo session logging and a logging server now, along with binaries to replay all those logs. Whether those LOC reflect the logging server, I don't know.

It literally replays in the terminal like a movie. It's nice, but I worry too much about the security implications (passwords captured, etc) to roll it out.

edit:

Ah yes, sudoreplay. You can see this video a playback via it. That's not the guy typing, that's sudoreplay time-accurately replaying what happens.

https://www.youtube.com/watch?v=8XHlowCiLaM

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

#109

Post by bee_rider »

charcircuit wrote: post #46
8fingerlouie wrote: post #40

Earlier quoted context omitted.

You can use Jails and limit access to hardware resources for each jail. Still not as dynamic, but will get the job done.

Sure, but this is not done automatically for the user.

For the types of computers BSD is typically run on, just unplug the webcam.

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

#110

Post by 1970-01-01 »

gmac wrote: post #101
1970-01-01 wrote: post #97

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

I 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, je…

Software 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.
Post reply on HN