65

long story short if you can execute code on a box it is usually straightforward to get root

(quote source)

The immediate implication of this quote (if it's accurate) is that if you're running a multi-user system and don't try your darndest to prevent all users from creating files with x permission set, the system is as good as compromised. The corollary is that operating a multi-user system, such as ones typically found in universities, that by design allow all students to do exercises in C, C++, assembly etc, is pointless, since any student can straightforwardly root this system.

Since running computer systems intended to be used by more people than their owners is not considered pointless, and privilege limiting facilities (users' rights management, sandboxing, etc etc) are not considered useless, I somehow doubt these kinds of comments. But what do I know?

Is it true that most Linux systems are straightforwardly rootable by anyone who can execute code on them?

Michael
  • 2,391
  • 2
  • 19
  • 36
gaazkam
  • 5,607
  • 11
  • 24
  • 37
  • 6
    No. But we had a saying that if you have *physical access* to a system you own it. – Peter - Reinstate Monica Oct 31 '18 at 00:43
  • 5
    Security that's hard but not impossible to break (with newly-discovered vulnerabilities) will deter casual abuse, especially when failed attempts will often be noisy. It's not by any means pointless to have security instead of giving everyone root intentionally. If the potential attackers are mostly students, you have a huge amount of power to investigate and punish them through academic / discipline channels that aren't available against anonymous attackers coming from a foreign country over the Internet. – Peter Cordes Oct 31 '18 at 03:40
  • 2
    Just so you know, you don't need the "x" permission set to execute code. You can provide code to an interpreter to read and execute. – JoL Oct 31 '18 at 16:51
  • @JoL Well then you're just executing pre-existing functions in an already made executable based on the input you give it. You don't usually get to execute code directly. – forest Nov 02 '18 at 01:18
  • @forest Redacted wall of comments for brevity. (a) I'm very grateful for your insightful answer (b) You mention risks of using `sudo` and link to a blog post that recommends `SSH`ing to root instead (c) My Uni instructor is adamant that `SSH`ing to root is a horrible practice and disabled by default for good reasons (d) I can't judge who is right (e) While I thank you for pointing me to (seemingly) well-founded opinions that differ from what I'm being taught (f) I feel between a rock and a hard place because I've made it a personal rule to only accept answers I'm 100% sure are 100% correct. – gaazkam Dec 03 '18 at 19:54
  • @gaazkam Fair enough. Whether or not SSHing as root is good or bad practice may be debatable (argument that it's good: modify .bashrc to hook sudo command to steal creds, which is trivial to prove. Argument that it's bad: it may encourage the user to run everything as root, even things that don't need to run as root). But no one can argue against the fact that a compromised non-root SSH user with sudoers privileges is exactly equivalent to root when a sysadmin logs in and simply enters their password! – forest Mar 07 '21 at 02:29

4 Answers4

90

No, this is not correct. While one may argue about the relative difficulty of finding and exploiting 0day vulnerabilities on Linux when you have local access, the security architecture itself of a modern Linux system (with an MMU) is designed to isolate different users and prevent privilege escalation. A non-root user cannot gain root without proper authorization without exploiting an extant vulnerability, and such privilege escalation vulnerabilities are very quickly patched as soon as they are discovered.*

It is possible, however, to abuse the human factor and gain root by exploiting misconceptions ubiquitous in the sysadmin profession. This of course relies on the sysadmin misunderstanding the security architecture of the system they maintain. A non-exhaustive list of examples:

  • Elevating privileges with sudo or su from an unprivileged but untrusted user.1

  • Tricking a sysadmin into running ldd on a malicious static executable as root.2

  • Abusing an insecurely installed binary.3

  • Dropping down to a lesser user from root, allowing a TTY pushback attack.4 5

* While this is ostensibly true, many deployments do not update themselves frequently enough, leading to live production systems being vulnerable to known bugs. An update being available does not guarantee an update being installed.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
forest
  • 64,616
  • 20
  • 206
  • 257
  • 3
    On a desktop machine I would say its not even the human factor. The whole linux desktop provides very little protection against bad processes running as the user. A bad process could just watch the keyboard input and wait for the user to run a command as sudo. The bad process now has root without ever being known to the user. – Qwertie Oct 30 '18 at 03:11
  • 5
    @Qwertie That's true for servers as well, although X11 on desktops does make that _slightly_ easier. It's a common misconception that `sudo` is safe on servers when you e.g. SSH in as an unprivileged (but possibly compromised) user and then elevate to root, as opposed to logging in as root directly. – forest Oct 30 '18 at 03:11
  • 6
    Wasn't the ldd trick deemed an exploit and fixed long ago? https://bugzilla.redhat.com/show_bug.cgi?id=531160#c16 https://lwn.net/Articles/746327/ If the system isn't properly updated, that one would work, but so would any other unpatched exploit. – Alcaro Oct 30 '18 at 09:53
  • 7
    "...such privilege escalation vulnerabilities are very quickly patched as soon as they are discovered." Hoo-wee, where do *you* work? Saying this *should* happen is one thing; implying that it always *does*...well, that's quite another. – Wildcard Oct 30 '18 at 20:33
  • 12
    @Wildcard It's quickly patched in mainline Linux, not necessarily in every company's specific installation or the distribution kernel they are using. – forest Oct 31 '18 at 01:41
  • The original claim was followed by a link to this [blog entry](https://webcache.googleusercontent.com/search?q=cache:efKwhGEiWiIJ:https://payatu.com/guide-linux-privilege-escalation/+&cd=1&hl=en&ct=clnk&gl=us) which talks about exploiting things like running services as root, users with '.' in their path etc. It also has tips on how to avoid being subject to this. – JimmyJames Oct 31 '18 at 16:31
  • @forest regarding the sudo vs logging in as root issue, remember that www facing servers get hammered constantly 24/7 by ssh root login attempts; does that make the best option disabling remote root and using `su` once you get in? – jrh Nov 01 '18 at 15:19
  • 1
    @jrh The best option is 1) keep the SSH port closed except when initiating the connection by using something like [`fwknopd`](http://www.cipherdyne.org/fwknop/) (this protects against constant port hammering, most zero-days that could happen, and unlike running SSH on a non-standard port, it's not just a matter of a few minutes of determined port scanning to get around) and (cont) – mtraceur Nov 01 '18 at 16:47
  • 1
    @jrh (cont) ..and 2) use public-private keys instead of passphrases everywhere possible (this matters much once `fwknopd` is in play, but it turns brute force attacks into "computationally infeasible" instead of "hope everyone with access has passphrases with entropy comparable to a standard private key"). – mtraceur Nov 01 '18 at 16:50
  • 1
    @forest I suspect the downvotes are because local privilege escalation vulnerabilities are dangerously common and frequent. From experience I can attest that most developers/admins adopt a "you'd have to already be on the box to exploit this so it doesn't really matter" mindset to local privilege escalation bugs, often don't consider how buggy behavior can be chained to get an exploit, and sometimes just don't understand how local privilege escalation happens (and I am concerned that for those people, this post is liable to contribute to a reinforcement of that misunderstanding). – mtraceur Nov 01 '18 at 17:00
  • 2
    @forest (cont) To be clear, your post is overall good in principle: the only way privilege escalation happens is by somehow causing existing vulnerable code that is already running with privileges into doing something it wasn't expected or supposed to do. I think the risk is that "without exploiting an extant vulnerability" can imply to some that they are rare or finding them is hard, and "are very quickly patched as soon as they are discovered" (aside from not matching my experience) overlooks that sometimes they are in the wild for years before white-hat discovery. – mtraceur Nov 01 '18 at 17:07
  • @jrh No, that is still not the best option. However, you absolutely should disable _password_ authentication for root login and instead use public key authentication. – forest Nov 02 '18 at 01:10
  • @mtraceur That's a good point. I've edited my answer to clarify. – forest Nov 02 '18 at 01:11
  • I still think this answer leans a bit too far in the neighborhood of implying local access is secure. If you look at platforms with high motivation for local privledge escalation, iPhones get jailbroken quite easily. The same is true for just about any protected platform, like say gaming platforms. The difference is in Linux there's little motivation to find, and reveal these exploits, but I suspect they're there in large numbers. I think the point of the original quote was that the attack surface with local access is MUCH larger than remote, though maybe not "straightforward" – Steve Sether Nov 19 '19 at 18:36
  • @SteveSether It really depends on where you're coming from. iPhone jailbreaks require a _lot_ of skill to pull off. Linux LPEs too. They exist, and there are a lot of them, but it is very far from "straightforward". Modern day Linux is not Linux of the 90s. – forest Nov 20 '19 at 08:43
  • @forest Finding the Jailbreak is hard, but once it is, exploiting it is as easy as a google search and pretty straightforward. – Steve Sether Nov 20 '19 at 14:06
26

To rephrase the quote - Privilege escalation vulnerabilities have existed and will continue to be found or created.

During the last week we have this little doozy in SystemD; what are we going to have next week, will it be patched in time, and how good is your patching regime?

You should assume that it's feasible that an attacker who can run on a box can probably obtain root access to their OS instance at some point regardless of what OS is in play. How "straightforward" such a task is perhaps debateable but if a user can run arbitrary code then it gives them plenty of scope.

James Snell
  • 888
  • 6
  • 8
  • 2
    There are plenty of additional hardening techniques, there is RBAC and SELinux, it all depends on too many "if"s to be made a general statement. You may often be true, but to phrase it like in the question shows arrogance. – Tom Nov 01 '18 at 05:43
  • The OP's question referred to *most* instances, not hardened ones or ones with whatever special sauce one chooses to apply. It's no good changing the parameters of the question to fit your taste. Or do we need a reminder about major flaws sitting in open source codebases for decades undetected? So, you should always assume that pwnage is possible if users can run arbitrary code. – James Snell Nov 01 '18 at 20:34
14

Exploiting a privilege escalation vulnerability is already hard enough, doing so while being certain that you don't leave a trace is much much harder. An Android user trying to root their phone can keep trying one exploit after the other, without worrying or having to cover up their traces. A student repeatedly trying to abuse sudo or spreading fishy executable files across the file share will likely get noticed and reprimanded or expelled.

By the way, the #1 way to get root access in a multi-user setting is to wait until a privileged user walks out of the workstation forgetting to lock it. I've seen that in two out of three universities I attended. However, the same remark about not getting caught applies.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
5

I think "straightforwardly" means "without human tricks and other social engineering". So the answer is - Yes, if the systems contain unpatched 0-day that leads to privileges escalation.

It could be an application-level 0-day. For example, if there are executables owned by root with setuid permissions which could affect arbitrary files. Latest reference is Xorg. You can look for potential vectors like this: find / -user root -perm -4000 -print 2>/dev/null. Another example - system service like systemd mentioned above.

Or it could be a kernel-level 0-day. They are quite rarer but more noisy because their coverage is much wider. Good reference is dirty COW.

Above is true if there is an absence of Mandatory access controls enabled which can prevent execution of some exploits.

Or ot could be even a boot-level attack. Secure boot is your friend then.

odo
  • 692
  • 4
  • 6