Are most Linux systems that allow non-root users to execute code straightforwardly rootable?

Question

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?

Answer 1

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

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

• Abusing an insecurely installed binary.³

• 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.}

Answer 2

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.

Answer 3

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.

Answer 4

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.