I was reading Ubuntu's documentation about root/sudo when I came across the following:
Isn't sudo less secure than su?
The basic security model is the same, and therefore these two systems share their primary weaknesses. Any user who uses su or sudo must be considered to be a privileged user. If that user's account is compromised by an attacker, the attacker can also gain root privileges the next time the user does so.
How can an attacker gain root privileges the next time the user does? Assuming sudo is disabled.
It's very simple actually.
sudo
is typically set to cache its authentication so you don't have to enter your password every time you usesudo
on a command. I believe the default cache time is something like 5 minutes.Thus if the attacker has access to a user account with
sudo
access, even without knowing their password, they can just wait for the next time the user performs asudo
. The attacker can then runsudo
right afterwards and get a root shell.I presume this is the scenario they are referring to when they mention "the next time the user does".
I think the case you are asking about has more to do with privilege escalation via su. Since it may be that only the user's password is compromised, the attacker cannot esacalate until he also has root's password. If the attacker installs a keylogger program or replaces su or something like that, he/she will be able to obtain the root password the next time the privileged user types it.
sudo -s
executes the users .bashrc. If you have access to that users account you can add lines to this bashrc that will be ran as root.I'd add something like that in, create a setuid copy of bash, so that I could run it later.
Edit: the question now seems to ask about cases where sudo isn't used.
First trick that comes to mind if i wanted to root privileges from a user using su would be to modify their path.
That's running fedora 11 with bash 4. Configs for su, shell environment stuff are pretty much default.
As you can see, I was able to change the path as the regular user, and this path wasn't reset by su (note
su -
would have reset it). Change their path in their shell rc, then put my own script into the new directory at the top of the path. Make a few copies (or symlinks) of it with names like ls, cp, mv, things that get ran often.Anyway, these are just examples, there's undoubtedly other similar scenarios. I think the point is that accounts which can su or sudo are something to be careful with.
Although sudo is commonly used together with su command, thinking sudo su is the only way to do is a mistake.
sudo has many options for setting what to execute by who (ether user of group of users) on which host. A fine-grained sudoers file (or LDAP entry, if sudo-ldap is involved) together with a clever mind of a sysadmin can end up in rules which may not compromise system security even the user account has been compromised.
let's see a real-word example:
If one does not let user sudo-exec su/bash or other shell neither directly (sudo su) nor indirectly (letting an editor spawn with root, which could be used to spawn shell - in this case, root), sudo is a friend of a system administrator and users too.
Returning to the question in topic, if sudo is disabled and su is the only way becoming root on a system, one would plant a fake su command (for example in ~/.../fakesu) and an alias like alias su='~/.../fakesu' in the rc file of the user's login shell.
In this case a simple su command (raise hands, who uses /bin/su for invoking) would end up calling the fakesu command, which may capture the password.
If a user's password is compromised and that user has sudo privileges, an attacker could run sudo su, and become root.
The principle is simple. Sudo only requires the user's password to perform activities as root. If someone was able to break into that user's account, he probably knows the password (or can easily figure it out).
With su, the case is a bit different, because it requires root password. However, an attacker could change the user's PATH to point to its own version of su (inside tmp or ./bin) that will save the root password somewhere.
Now you added that sudo is disabled. The link you provided don't talk about that. They mention the case where sudo or su are configured for that user and an attacker uses that as leverage to get root.