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

251–260 of 287 posts

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

#251

Post by burnt-resistor »

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.

QEMU is more well-known and tested than Firecracker; i.e., a hacked version is used in Xen used everywhere in the past decade while Firecracker is primarily an Amazon-only thing. Cloud Hypervisor, Dragonball, and StratoVirt aren't well-known or battle-tested IMO. The problem is none of these possess true manageability and isolation features of any solid type 1 hypervisor which makes Kata equivalent to a user-space application rather than a reliable platform with harder resource isolation guarantees.

https://github.com/kata-containers/kata-containers/blob/main...

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

#252

Post by burnt-resistor »

worthless-trash wrote: post #240
tptacek wrote: post #216

Earlier quoted context omitted.

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.

Isolation guarantees: Separate metal > type 1 hypervisors > type 2 hypervisors > containers > processes > OS threads > cooperative threads ;)

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

#253

Post by IlikeKitties »

mathverse wrote: post #246
IlikeKitties wrote: post #137

Earlier quoted context omitted.

You are literally saying that hardening the kernel is the same as having the desktop environment hardened and a basis for app isolation. And to add a cherry on top of that both secureblue and kicksecure use almost all the same hardening additions to the linux kernel as grsecurity. You do not understand what you are talking about because if you did you'd be embarrassed for how braindead your response is.

Name the additions.

You have already proven you don't understand the difference between kernel and userland hardening, why should i bother working for you, google it yourself.

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

#254

Post by nullc »

jonathanstrange wrote: post #133
faceplanted wrote: post #127

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

Often worse than the original system, because the writers expertise and motivation are different.

At times the authors who rewrite-in-foo are just motivated to expand the foo ecosystem and are not primarily interested in making a working program, much less in possession of the requisite subject matter expertise or focus.

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

#255

Post by nullc »

udev4096 wrote: post #23
subscribed wrote: post #5

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)

Qubes is definitely hard to daily drive. With it's ancient default XFCE design, it looks really ugly. Plus no hardware acceleration

I think XFCE is much more attractive and usable than gnome stuff. In particular the buttons have borders so you can actually find them.

Video performance is a fair criticism for sure.

But is perpetual 0day RCE's in browsers and other highly exposed software is not running Qubes really a credible choice?

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

#256

Post by galangalalgol »

kbolino wrote: post #228
galangalalgol wrote: post #225

Earlier quoted context omitted.

Separate processes running the same shared instructions. If you compromise and modify those shared instructions, the othe container runs instructions of your choosing.

Layers are COW so one container modifying a layer has no effect on other containers started from the same image. Of course, preexisting vulnerabilities will remain but they'd have to be separately exploited in each container.

I learned something new today! Thank you.

Edit: to be clear, I knew the disk was COW but I thought it saved memory by loading one instance of shared objects into memory.

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

#257

Post by johnisgood »

Dylan16807 wrote: post #244
johnisgood wrote: post #173

Earlier quoted context omitted.

Yup, hence why the downvotes. :( I thought it was a no-brainer, but I guess not.

Saying "a lot" and especially that it's still "a lot" is not a no-brainer.

Some. More than enough. Potentially two, critical ones. Is that better?

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

#258

Post by Xylakant »

faceplanted wrote: post #250
johnisgood wrote: post #173

Earlier quoted context omitted.

Yup, hence why the downvotes. :( I thought it was a no-brainer, but I guess not.

I see what you mean now. The way you phrased it came off as much more a critique of the language used and/or the developers using it, rather than the simple fact of it being a rewrite of a complex tool. Also does `sudo` not have a spec or any existing unit tests for the previous vulnerabilities that they can benefit from? I'd be pretty shocked if there wasn't a lot of regression testing and documentation available to…

Rewrites by engineers can also uncover cases where the original tool does not conform to its own spec, this rewrite uncovered two issues with the original sudo.

One of our engineers involved in the project wrote about the testing approach they used and about the issues they found here https://ferrous-systems.com/blog/testing-sudo-rs/.

Later, a dedicated security audit for the rewrite was performes which uncovered three issues, one of which also affects the original sudo implementation. https://ferrous-systems.com/blog/sudo-rs-audit/

I generally support the notion that rewrites of large complex code bases are usually a bad choice, but sudo is not a particularly large codebase not is it particularly comples - it's just particularly sensitive. In those cases, I believe the tradeoff can fall the other way - rewriting old, feature-stable codebases (to a reduced scope) can lead to improvements on all axis.

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

#259

Post by Dylan16807 »

johnisgood wrote: post #257
Dylan16807 wrote: post #244

Earlier quoted context omitted.

Saying "a lot" and especially that it's still "a lot" is not a no-brainer.

Some. More than enough. Potentially two, critical ones. Is that better?

I bet you the existing program also has two critical bugs. It's replacing imperfect with imperfect and rewrites are not necessarily worse. Especially if a program grew a ton over time and you can give it a better structure and a better spec document.

There are systems where you really want to preserve accidental quirks of behavior that other things depend on. Sudo I think is not one of those.

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

#260

Post by simoncion »

akdev1l wrote: post #218
simoncion wrote: post #20

Earlier quoted context omitted.

> ...for most modern single-user linux devices, local privilege escalation means almost nothing. I haven't actually looked at the numbers, but I strongly suspect that it's true that the overwhelming majority of single-user Linux devices out there are Android devices. If that's true, then it's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root woul…

Android is not a single user system. Every app, every service basically everything gets its own user. Applications have different user IDs and different SELinux contexts. Android security is tight

Android is nearly always a single user system in the sense that TheDong was using. Look at the context a little further down in the guy's comment:

> Like, I'm the only user on my laptop. If you get arbitrary code execution as my user, you can log my keystrokes, steal my passwords and browser sessions, steal my bitcoin wallet, and persist reasonably well.... and once you've stolen my password via say keylogging me typing `sudo`, you now have root too.

In this context, "single user system" means either "single human using the system", or "one human physically sat in front of the system's 'console' at one time". It's in contrast with systems that have multiple human users logged in and using the system simultaneously. So, nearly 100% of "single user systems" of this type will have software running under different "user" accounts on the system, but still meet the definition, because those accounts are actually "machine" or "service" accounts.

I do think that this overload of the terminology is bogus and confusing. It should be called something like "single seat system", but here we are.

> Android security is tight

Yep. That's what I said: "[I]t's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root would actually be a significant gain in access."

Post reply on HN