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

231–240 of 287 posts

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

#231

Post by eddd-ddde »

uncircle wrote: post #123
PhilipRoman wrote: post #57

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…

https://xkcd.com/1200/

The best is they absolutely can install drivers without your permission unless your system is encrypted. So it's even worse!

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

#232

Post by holowoodman »

stefan_ wrote: post #219
holowoodman wrote: post #178

Earlier quoted context omitted.

For the last 10 years or so, namespaces in Linux were the source of the absolute hightest number of local privilege escalations and sometimes even arbitrary code executions in kernel space. Building a kernel without user namespace support has been goto-advice for multiuser systems for almost as long. Ubuntu is just late to the game because they mostly have server or single-user-desktop customers.

Actually I think device drivers got you beat there, but no ones suggesting we break them for users safety. Ubuntu today is more user hostile than Windows.

Device drivers are worse if you just count the numbers. But they are usually far less exploitable because very often you need to have the corresponding hardware plugged in or even need to manipulate said hardware to provide crafted inputs. So in reality, device driver problems are almost never exploitable.

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

#233

Post by gosub100 »

karlgkk wrote: post #205
NicolaiS wrote: post #170

Earlier quoted context omitted.

After the Linux Foundation became a CNA (CVE Numbering Authority), it started issuing CVEs for a broad range of "vulns", such as local denial-of-service, memory errors with no viable exploit path, and logic flaws lacking meaningful security implications. Looking at the raw number of CVEs is not very meaningful

> memory errors with no viable exploit path i dont appreciate putting "vulns" in scare quotes, if that was your intent swiss cheese theory. all it takes is someone changing a component that allows that vulnerability to be chained into an exploit, which has happened many times. these should be tracked, and in fact, it's very helpful to assign cves to them but yeah, raw numbers is less useful. in fact, cves as a "is it…

Additionally, having simpler vulns labelled allows more juniors to work on coding fixes for them.and getting their feet wet in that particular sub field.

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

#234

Post by mort96 »

rcxdude wrote: post #184
NicolaiS wrote: post #170

Earlier quoted context omitted.

After the Linux Foundation became a CNA (CVE Numbering Authority), it started issuing CVEs for a broad range of "vulns", such as local denial-of-service, memory errors with no viable exploit path, and logic flaws lacking meaningful security implications. Looking at the raw number of CVEs is not very meaningful

Indeed. They issue a CVE for every bugfix, because it's long been the position of the linux maintainers that there's no meaningful distinction between a security bug and a regular bug.

And I'm not sure I can fault them for that, tbh. When you're a kernel, it's very hard to prove that something is a "non-security" bug -- especially when we count DoS as a security bug.

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

#235

Post by dspillett »

salawat wrote: post #105
ikekkdcjkfke wrote: post #90

Earlier quoted context omitted.

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.

> It only became […] that machines give a shit about who you are once we started using computers as the basis of business systems.

One we started using connected machines for much and people with flexible though morals noticed that there was trust in the system(s) ripe for exploitation for fun or profit or both.

I remember SMTP hosts being open by default because it wasn't a problem, that very quickly changed once spam was noted as potentially profitable.

There were accounts all over from quite early on, in academic environments before businesses took much of an interest, if only to protect user A from user B's cockups ("rm -rf /home /me/tmp") though to some extent also because compute time was sometimes a billable item, just not on single user designed OSs¹.

[1] Windows, for example, pre NT & 95 (any multi-user features you might have perceived in WfW 3.x were bolted on haphazardly and quite broken WRT actual security)

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

#236

Post by int_19h »

jowea wrote: post #197
Asooka wrote: post #118

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

There's been some work on alternatives to setuid sudo. For example run0 from systemd.

https://en.wikipedia.org/wiki/Doas is all you need

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

#237

Post by sedatk »

subscribed wrote: post #5
hbogert wrote: 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.

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)

> feature-wise they far exceed Windows

I tried Ubuntu last year, and it felt very limited compared to Windows. It lacked very basic features like face/fingerprint login, hybrid sleep, factory reset, live FDE (or post-installation FDE), fast fractional HiDPI, two-finger right-click, "sudo" on dock etc.

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

#238

Post by jart »

PhilipRoman wrote: post #57

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…

Or you could just use NetBSD like SDF does.

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

#239

Post by surajrmal »

londons_explore wrote: post #62
lima wrote: post #44

Earlier quoted context omitted.

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.

A lot of code to do very little user visible changes is the nature of operating systems. Making light of the work who work on chromeos just makes you sound ignorant.

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

#240

Post by worthless-trash »

tptacek wrote: post #216
burnt-resistor wrote: post #211

Earlier quoted context omitted.

They're slow and so unsuitable for dev work. They might be somewhat better for prod, but it depends on a wide selection of unproven hypervisors.

Which "unproven" hypervisors are those? Kata works with Firecracker.

I think they mean in regards to cross kernel attacks. vms didn't protect across speculative execution attacks.

I believe there are even more course grained timing attacks with dma and memory that are waiting to be abused.

Post reply on HN