63

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?

  • 6
    No. But we had a saying that if you have physical access to a system you own it. – Peter A. Schneider Oct 31 '18 at 0: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 3: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 2 '18 at 1: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 SSHing to root instead (c) My Uni instructor is adamant that SSHing 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 3 '18 at 19:54
91

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.

  • 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 3: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 3:11
  • 6
    Wasn't the ldd trick deemed an exploit and fixed long ago? bugzilla.redhat.com/show_bug.cgi?id=531160#c16 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 9:53
  • 6
    "...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 1:41
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.

  • 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 1 '18 at 5: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 1 '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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.