Hacker News new | ask | show | jobs
by sneak 363 days ago
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.
4 comments

An exploit chain, like combining it with the PAM issue they mentioned in the very same article, affecting Fedora.
The article was about two issues that combine to make a single local-privilege-escalation, so the PAM thing isn't a separate exploit chain, it's just part of getting local root in this vulnerability.

What the parent poster meant is that you first need a way to run arbitrary code before local privilege escalation matters, so the exploit chain has to include _something_ that gets you local code execution.

I tend to agree with the parent poster, for most modern single-user linux devices, local privilege escalation means almost nothing.

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.

If you have a local privilege escalation too, you still get my passwords, bitcoin wallet, etc, and also uh... you can persist yourself better by injecting malware into sshd or something or modifying my package manager? idk, seems like it's about the same.

> ...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 would actually be a significant gain in access.

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

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

Does Android use Udisks? I assumed it did not, due to the difference in architecture over most traditional GNU/Linux desktop systems
I have no idea if Android uses udisks. It has been something like a decade since I last looked at 'ps' output on an Android machine, so any information on the topic I might have had has faded away with time.
Some services dont run as the same user logging into the laptop.
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
Usually they don't need to be root to access and exfiltrate data anyway.
An attacker doesn't need a shell server to run code locally, you chain it with an exploit to a service and you have root and now have lateral attack capabilities.
There are plenty of shell servers in academic environments...