Live data from Hacker News

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

bleepingcomputer.com

141–150 of 287 posts

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

#141
post #87
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…

Ubuntu is switching to a Rust implementation of sudo: https://www.phoronix.com/news/Ubuntu-25.10-sudo-rs-Default Repo here: https://github.com/trifectatechfoundation/sudo-rs It's permissively licensed, unfortunately. Wonder why. It's not a library. But it ought to improve security in the long run.

Read the sudo license that argument don't make sense when sudo license is even more permissive

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

#142

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

> reliant upon PAM for authentication and don't support shadow passwords

PAM supports a shadow password file as its default configuration. Did you mean something else?

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

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

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

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

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

#144

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…

Given this. Why is every linux device not rooted then.

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

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

#145

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

And those 80 daemons are started via various systemd and dbus interfaces, and some via other means. If you have a daemon disruptive to your session (like ibus overriding the effect of setxkbmap in a i3 session), and you want to disable it... good luck with finding out what started it.

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

#146

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.

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

#147
post #73

Earlier quoted context omitted.

OpenDoas, a portable version of OpenBSD's doas, has 4260 LoC while doing most you'd expect. Sudo just has a lot of policy tools that most don't even know about, but add to its surface area.

OpenDoas is used by default by Alpine linux for example.

I remember last time I installed it, there was neither sudo nor doas preinstalled.

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

#148
post #129
post #78

Earlier quoted context omitted.

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

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.

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

#149
post #108

Earlier quoted context omitted.

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 typin…

have you heard of script/scriptreplay?

  script --log-timing file.tm --log-out script.out
  # do something in a terminal session ...

  scriptreplay --log-timing file.tm --log-out script.out
  # replay it, possibly pausing and increasing/decreasing playback speed

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

#150

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…

Wouldn't Android's kernel have most of the hardening steps / disabled features described in GP's comment?

No. Things like eBPF, strace, and packet filtering are enabled. Android uses SELinux and other facilities to limit the amount of code the kernel will allow to access these features. Big difference from their being compiled out of the kernel entirely as the OP suggests is necessary.
Post reply on HN