Live data from Hacker News

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

bleepingcomputer.com

61–70 of 287 posts

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

#62
post #44

Earlier quoted context omitted.

That'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)

Chromium OS gets very close, they also have fully-functional VM-based isolation for Linux applications with GPU acceleration. Unfortunately, there's no popular non-Google distro of it.

The fact that Chromium OS has been teetering on the edge of deprecation/merging with Android/Fuchsia for a decade I think has deterred people from building stuff on top of it.

It also seems to have a lot of new code every year for very few new features. It's as if they get every new intern to rewrite a bit of the innards, and then next summer another intern rewrites it again.

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

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

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

#64
post #63
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.

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

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

#65

Earlier quoted context omitted.

That'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)

> I wish I had something like GrapheneOS on desktops (yes I know about Qubes) SecureBlue and Kicksecure are the closest equivalents.

Don't know much about SecureBlue but Kicksecure isn't comparable to Qubes at all. It's a hardened distro, not a way to isolate workloads through virtualisation. Depending on what you're trying to achieve they can both fit but they are fundamentally very different in their approach to security.

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

#66
post #63
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.

sudo 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)

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

#67

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.

> I'm pretty sure, that the BSD family is pretty mature and secure. Not to mention illumos-based systems too.

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

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

#68
post #61

Could someone describe what 'allow_active' privileges is on Linux?

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

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

#69
post #27

Earlier quoted context omitted.

What especially feels like an experiment is container technology.

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

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

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

#70
post #6
post #2

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

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

this type of exploits are goldmines for attackers, it means they have a window of a few month to years to turn any basic access into root. It doesn't have to be a super complex exploit chain, anyone running wordpress botnets it going to add this to their arsenal
Post reply on HN