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

261–270 of 287 posts

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

#261

Post by Dylan16807 »

shakna wrote: post #245
Dylan16807 wrote: post #242

Earlier quoted context omitted.

> Pipewire runs under the pipewire user, managed by systemd or OpenRC. Which means any of their managed processes can start a new pipewire user process. The box I checked has no pipewire user and it's running under the account I logged in with. > A local priv-sec is one exploit [0] away from a remote one. That only matters for accounts that talk to the outside world. If I'm the only user, I'm not depending on securit…

If you play sound, such as from a browser, or a file you didn't record yourself, then your account is talking to the outside world.

Yes, my account is. It's doing the decoding, not the pipewire account. It's not a cross-account attack that I need to defend from.

Maybe I wasn't clear. I'm saying exactly one account has meaningful exposure to the outside world, and it's the only one with valuable files. Not none, but also not multiple. It's effectively single user from a security perspective.

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

#262

Post by johnisgood »

Dylan16807 wrote: post #259
johnisgood wrote: post #257

Earlier quoted context omitted.

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.

Someone said this: https://news.ycombinator.com/item?id=44364842

I agree.

How about we just start using doas, anyway?

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

#263

Post by quotemstr »

galangalalgol wrote: post #256
kbolino wrote: post #228

Earlier quoted context omitted.

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.

> thought it saved memory by loading one instance of shared objects into memory

It does! The trick is that it loads the shared object read-only as far as the CPU is concerned. If a program tries to modify the memory, the CPU (I'm simplifying a lot here) throws an exception. The kernel catches that exception, makes a copy of the memory the program is trying to modify, puts the copy of the original memory at the same address as the original read-only memory, and tells the program to re-try the write operation, which now succeeds. All of this happens without the application doing the writing being aware of what's going on. From its point of view, writes Just Work.

This way, you get the memory savings of sharing and the flexibility to do writes all without the security problems of shared mutability.

You might enjoy reading about OS virtual memory operation more generally!

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

#265

Post by quotemstr »

eyberg wrote: post #226
zamalek wrote: post #166

Earlier quoted context omitted.

If you weren't aware, containers aren't a security boundary. Things like bubblewrap are.

bubblewrap is actually worse - there are known escapes in there that haven't been fixed for years

Wait. What? What escapes? Is it that bubblewrap not faithfully implement the policy you give it or that there are surprising gaps in the kernel's namespace isolation?

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

#266

Post by mkj »

rob_c wrote: post #196
Dylan16807 wrote: post #192

Earlier quoted context omitted.

Relax, someone else already explained it without shouting.

At the time they hadn't and I'm fed up of the jumping to conclusions that env vars are the cause of any security issue. This is blaming poor code from poor devs on expert features from UNIX all to often. Worrying when said person has authored a widely used security product(!). This is a bad trend in the industry that needs to stop.

I'll say it again - environment variables or pam_env aren't expert features - they're primitive. They were a contributing factor in the first privilege escalation.

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

#267

Post by tptacek »

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

Earlier quoted context omitted.

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

Firecracker is probably the 2nd or 3rd most widely deployed hypervisor in production deployments. I think "Amazon-only" isn't doing the rhetorical lifting you mean it to do. The idea that it's "equivalent to a user-space application" makes very little sense.

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

#268

Post by rob_c »

mkj wrote: post #266
rob_c wrote: post #196

Earlier quoted context omitted.

At the time they hadn't and I'm fed up of the jumping to conclusions that env vars are the cause of any security issue. This is blaming poor code from poor devs on expert features from UNIX all to often. Worrying when said person has authored a widely used security product(!). This is a bad trend in the industry that needs to stop.

I'll say it again - environment variables or pam_env aren't expert features - they're primitive. They were a contributing factor in the first privilege escalation.

Hardly, it's a minor coding bug to do with defaults.

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

#269

Post by akdev1l »

simoncion wrote: post #260
akdev1l wrote: post #218

Earlier quoted context omitted.

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

The context is that on a traditional Linux laptop/desktop you are in fact running everything as one user.

Firefox, the desktop environment, your password manager and even `sudo` are traditionally all running as your own user.

This is not true in Android whatsoever.

Being multi-seat or not has little security implications - most traditional Linux systems can handle multi-seat but they’re still limited in security by running everything as a single user

And no nearly all 100% of Linux systems do not run proper multi-user configurations because none of the most popular distributions ship like that. Not in the context of desktop usage anyway.

Servers do use multi-user configuration but that’s not what we’re talking about here

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

#270

Post by Dylan16807 »

johnisgood wrote: post #262
Dylan16807 wrote: post #259

Earlier quoted context omitted.

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.

Someone said this: https://news.ycombinator.com/item?id=44364842 I agree. How about we just start using doas, anyway?

I'm not well versed in the motivation of this project.

But yeah a simpler program is probably good in this situation.

Post reply on HN