Do sudo and .profile/.bashrc enable trivial privilege escalation?

Question

First of all, let me mention that I’m assuming a configuration as set up by current Linux desktop distributions (e. g. Debian, Fedora). I’m sure that there are methods which, if implemented, would mitigate the issues described here. What I’m interested in is the security “out of the box”.

It seems to me that the fact that shells execute files like ~/.profile or ~/.bashrc, which allow complete manipulation of a user’s execution environment and are owned by the user, destroys any hope that a program like sudo can be run securely. The problem is that any malicious program running as the user can edit these files to, for example, modify the PATH environment variable to include a fake sudo executable, such as PATH="$HOME/.evil:$PATH", where the malicious program also created a file $HOME/.evil/sudo. Then, the next time the user types sudo in a shell, the fake sudo will be run instead and can record the typed password. Thus, the fake sudo can obtain root privileges even though the original malicious program only had user privileges.

In fact, the default .profile file created by my installation of Ubuntu includes the following lines:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

so there is no need to even modify .profile – just create $HOME/bin/sudo and it’s already first on the PATH!

My point is not that it is already “too late” when arbitrary malicious code is run or that this attack could be noticed by the user (I suppose it is similar to a phising attack). I expect that a malicious program running as a user can do anything that the user could. What I would not expect is, however, that it can do more than that user (root privileges).

My question is, in essence:

1. Is it true that the system sudo executable can be circumvented in this way?
2. Why are desktop Linux systems, by default, set up in such an easily exploitable way? Shouldn’t the default way to invoke sudo make sure that it is, in fact, the executable provided by the system (nobody is going to type /usr/bin/sudo every time)? Since sudo performs system-critical security operations, the possibility to shadow its location using the PATH variable seems to bring a lot of risk with little benefit. In such an environment, it seems that using sudo is fundamentally insecure and one would be better off enabling login as root and logging in on a separate TTY.

Answer 1

Anything you can do on a compromised account, an attacker can do as well.

Fundamentally, this is because Linux providers isolation between users, not between individual processes running as the same user. Any process running as a given user is considered to have equivalent capabilities as any other processes running under that user.

Is it true that the system sudo executable can be circumvented in this way?

Yes, and in other ways as well. If you elevate privileges to root on a compromised unprivileged account, you compromise root. If you drop privileges from root using su to an unprivileged account, you also compromise root! You can never safely elevate privileges on an untrusted account. While it's possible to exploit the system using PATH, it's also possible to hijack the bash process itself to sniff key input. Disabling execution with noexec is further not useful because interpreters (bash, python, perl, etc) will still run. The noexec option is not and has never been designed as a security feature, despite it being regularly peddled as such.

An incomplete list of ways an attacker could hijack the use of sudo or su:

• Using the LD_PRELOAD variable on the parent process (e.g. bash).

• Hooking the parent process with ptrace() or process_vm_writev().

• Sniffing or injecting keystrokes into the terminal emulator using the X11 protocol.

• Creating aliases or functions to wrap the actual sudo executable.

I explained these in more detail on my answer to another question.

Why are desktop Linux systems, by default, set up in such an easily exploitable way?

Elevating privileges on an untrusted account is not something you are supposed to do. Not to mention, desktop Linux is an afterthought in the grand scheme of the general *nix architecture. It is a failure of security theater incessantly repeating the same bad advice, not a failure of the security architecture of Linux itself. People repeatedly say to use sudo for root because many new users will instead run everything as root, even their browsers! In this case, it is better to be using sudo. It is harmful in the case where the user is already smart enough not to use root for everything.

Note that sudo is highly configurable and can be designed to allow only certain commands. This is where it really shines. You can configure sudo to only allow you to run apt-get update as root (with or without a password), and deny everything else. That would additionally restrict an attacker from doing anything other than... well... doing a software update.

It's important to remember that, even if you configure it to only allow running certain commands as root, you can still shoot yourself in the foot if you whitelist programs that are not designed to run as root via an untrusted user. I saw a real-life example of someone trying to run VeraCrypt in this way and explained why it is insecure. The idea was that VeraCrypt is safe to run as root, so it should be safe to use sudo to elevate it to root as an untrusted, unprivileged user. It turns out the idea is flawed, and allows trivial privilege escalation!

Shouldn’t the default way to invoke sudo make sure that it is, in fact, the executable provided by the system (nobody is going to type /usr/bin/sudo every time)?

Typing the full path will not protect you! You can easily create a function that contains a leading /, and it will override the real executable. Even if the executable did make sure that it is genuine and attempted to defeat sniffing, a malicious process could hijack the bash process and sniff keystrokes independently of sudo, making it impossible to detect from its point of view.

$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!

In such an environment, it seems that using sudo is fundamentally insecure and one would be better off enabling login as root and logging in on a separate TTY.

This is always the case. Note that even logging into another TTY is not perfectly safe. You should use SAK, the Secure Attention Key combination, to ensure that you are interacting with a genuine login session (agetty or logind, for example). SAK is a key combination that the kernel listens for (and thus cannot be repressed by userspace). When it detects it, it will kill every process in the current TTY, triggering the login prompt to appear. If you have switched to a genuine, uncompromised TTY, then it will only cause the prompt to disappear and reappear. If you are on a hijacked TTY, it will kill the malicious process and bring back the genuine login prompt.

Answer 2

First, changing .profile will not automagically achieve privilege escalation. The user affected must already have sudo rights.

1 - sudo is not being circunvented. You are running something else in place of it. You could change .profile and add alias sudo=~/.evilsudo and achieve the same.

2 - You think about the lazy way of configuring sudo. On a desktop environment, that would be the case, but not on a server environment. On a server environment, /etc/sudoers should grant the user only the commands he will need to run to execute his task. You would expect the Oracle admin to run sudo service oracle, so that would be on sudoers. Not oradmin ALL=(ALL:ALL) ALL for example.

And it's already too late if someone runs code on your account. Anybody changing your .profile could start another shell capturing every single key press, and you lose not only your password, but everything else you type on it. Remote ssh passwords, database passwords, ftp passwords, anything. If your .profile is compromised, it's game over.

If you really want to protect the user against this, mount every single user-writable directory as noexec. This way ~/bin or /tmp or whatever else will not have permission to execute anything. You marginally increase security and dramatically decrease convenience.