Security of root terminal (su -) when logged into X

Question

I often log into X as normal user (of course), open terminal and switch to root:

su -

I have then a terminal owned by user but effectively with root privileges.

Are there any security issues in this situation?

Can a malware/exploit running under normal user potentially get access to the root console (possibly by exploiting some bug in X server?

Is this less safe, than if I had switched to text console (Ctrl+Alt+F1) and logged in as root directly ?

Clarification:

I have to enter the root password every time I switch to root using su -

Answer 1

Yes, it is less safe than if you switched to text console and log in as root directly.

Proof 1:

If you are logged in as root in a terminal, another process can send commands to that terminal.

Simple proof of concept:

1. Open a terminal, place in in the top left corner of the screen and switch to root.
2. Open a second terminal that does not overlap the first and type:

$ xdotool mousemove 100 100 click 1 && xdotool key l && xdotool key s && xdotool key KP_Enter

xdotool

Proof 2:

xinput can read all keyboard strokes

Use

$ xinput list

to identify the id of your keyboard and

$ xinput test id

to see which keystrokes are pressed. This will also display the keystrokes from the su terminal and reveal your password.

xinput man page

Answer 2

If your low privileged user has run malware under their privileges it is possible for that malware to have changed your users path and created a different "su" executable. When you open a terminal as your low privileged user the evil su is now first on your path so when it prompts you for your password you have lost control of the password.

This would be avoided if you switched to a text-console and logged in as root. However if you switch to a text-console login as yourself and su to root, your in the same situation as doing this from X. Note it may be possible for a malware to intercept the ctrl+alt+F1 and trick you into entering username and password but I suspect this would be much harder and may require more privileges.

Also note that local privilege escalations are very common, so once malware is running as any user, it is possible that that malware is able to get root though privilege escalations.

Answer 3

I am not familliar with linux internals to a great extent, so take this answer with a grain of salt.

When you log into X server as a normal user, all of the processes spawned are of the privileges granted to that user. The processes have restricted access to the system, the extent of which is enforced by operating system configuration, but are free to interact with other user processes. Because of this, the process memory adress space is accessable, and most likely writable by all other processes owned by this user. When you elevate your privileges by running the su program, the new subprocess, thread, whatever it may be, is launched by the parent process running as the normal user.

With this in mind, it is possible to imagine a scenario where an injection of code is done into this parent process, in order to get access to the internal memory space of that victim process. If so, it is theoreticly possible to intercept the session and privilege "token" to obtain root access.

I can see this done in two different ways: - Set a hook for a launch of su program and divert the flow to elevate several processes, instead of just the desired one. - Intercept an active session, and inject a request to spawn or elevate a different process.

Both of these scenarios would require arbitrary code execution on a victim machine, so it would be a later stage of the compromise. It might make a difference if you run X or not, in a sence that a correct process to inject into might be harder to know about, rather than the default bash.

In any case, I would think that it is feasable to perform such an attack, but the code to do so would have to be quite targeted, and unless you are a victim of an APT campaign, the chances of someone rooting your box by stealing your 'su -' comand are close to none.

I have no practical knowledge of how to pull of such a stunt on linux, so if I am wrong about the above points, feel free to correct me.

Answer 4

Using root (in terminal) in a user-level account might give you data insecure that may result in malware exploit in cross terminal exploitation. So, basically just use full root access.

Switching to root in a user-level account is quite a harsh thing to do. So, it's better if you switch to root every time you log in simply by ->

First edit the file /etc/login.defs and uncomment the following line (remove the '#' in front):

NO_PASSWORD_CONSOLE tty1:tty2:tty3:tty4:tty5:tty6

You have to do that so it doesn't ask for a password once you log in.

Second, edit /etc/inittab. This file is a bit compicated so it helps if you're familiar with it a little, but if you're not just work on the following line:

c1:12345:respawn:/sbin/agetty 38400 tty1 linux

You want to tell the agetty program to execute an auto login program (we will write this below). Replace the line above with the follwing:

c1:12345:respawn:/sbin/agetty -n -l /usr/sbin/autologin 38400 tty1 linux

The /usr/sbin/autologin program doesn't come with your system, you have to write it and compile it yourself, but it's pretty easy. First create an empty text file and add the following contents to it:

int main() 
{
  execlp( "login", "login", "-f", "shafiq", 0);
}

Replace shafiq with the name of the user you want to log in automatically and save the file as autologin.c.

Then compile the program like this (you have to be root for that to work):

cc autologin.c -o /usr/sbin/autologin

And that's it. When your machine finishes booting it will execute the autologin program which will log in as the user you specified in autologin.c and because you edited /etc/login.defs it won't ask for a password.

Now to execute a program after it logs in just edit .bash_profile in the user's home directory (create the file if it doesn't exist) and append the command you want to run at the end of that file, for example this is my .bash_profile, all it does is run pico:

pico

And if you feel unsafe of doing this, try to encrypt your BIOS during boot up. And let's see if anyone can open your device even at the very early booting up stage of whatever device you're using.

Regards.

Answer 5

Yes it would be safer to open up a new console and login as root. When you use su - you are piping a root session to you normal user session. If there was an attacker that had shell access to your normal account he could hijack that session you have with root. He might not be able to hijack X session however he could hijack the connection between normal user and root user.