I'm curious about the security of leaving a root shell running inside a detached screen session. I typically never do this.

Aside from the potential of my non-root user account being compromised (password exposed, ssh key compromised, etc), are there other vectors of entry into a detached, password-protected screen session I should be worried about, or can a detached screen session be considered inert?

  • This is not an answer because I don't know it, but I don't think it makes any difference between doing like you said and leaving the job to sudo. – phunehehe Mar 4 '11 at 14:52
  • 7
    @phunehehe There is a difference because when a job completes, sudo deactivates while a true root shell remains open. – Michael Mar 4 '11 at 14:55

I think it is a security issue, because that "Aside from the potential of my non-root user account being compromised" can be rather large.

But there are other increased risks beyond that. For example, you've now opened yourself up to a theoretical exploit which allows one to change permissions in the screen socket dir (/var/run/screen on my system, but sometimes /tmp is used). That exploit now has an path to getting root, which it might not otherwise.

sudo has other advantages, if you can train yourself to use it for each command rather than doing sudo su -. It logs actions (which, unless you're logging remotely, doesn't meaningfully increase security, but does give you a trail of what you've done). And it helps prevent accidents by requiring intentional escalation for each command, rather than switching to an entirely-privileged session.

  • 1
    Though no such exploit is known now, I'm going to keep on not leaving root shells open in screen. Risks to the user account are sufficient as it is. Thanks. – Michael Mar 4 '11 at 15:42
  • -1 If I have an exploit that can change file permissions I don't need to hack some running screen. I can do whatever I want with the system. – Let_Me_Be Mar 4 '11 at 18:08
  • @Let_Me_Be — it depends on which file permissions your exploit lets you change. Maybe you can only do a few specific things under certain hierarchies. That's not so far-fetched. – mattdm Mar 4 '11 at 18:24
  • Screen itself has a large attack surface. I don't have a full attack to show, but there are clear weaknesses. – Gilles Mar 4 '11 at 21:16
  • correct me if i am wrong, but the screen app is interfaced to via a shell session (either directly on the system console, or via a ssh session). as far as i am aware it's not a networking protocol as such. therefore it's as secure as your ssh session or terminal session is. if some has access to the ssh session, or your physical machine, all bets are off. if they have enough access to get to any sort of command line under any user account, then you might as well throw away your machine's security anyhow. – unsynchronized Jul 28 '16 at 14:22

If you have a root shell in a screen session (detached or not, password-protected or not), and your screen executable is not setxid, then an attacker who gains your privileges can run commands in that shell. If nothing else, they can do it by ptracing the screen process.

If screen is setuid or setgid, and the session is detached and password-protected, then in principle it takes the screen password to run commands in that shell. If this principle holds, someone who'd only compromised your account would have to put a trojan in place and wait for you to type the password. However the attack surface (i.e. the number of places where things can go wrong due to a bug or misconfiguration) is uncomfortably large. In addition to the basic system security features, you're trusting:

  • screen to get the password check right.
  • screen to prevent access to the session by other means.
  • screen to use the OS access control mechanisms properly (e.g. permissions on the pipes).
  • the kernel to perform the ptrace security checks correctly (this is a frequent source of vulnerabilities).
  • the running shell not to do anything stupid.
  • some other feature not to bite you.

“Some other feature not to bite you”: yeah, that's vague. But it's always a concern in security. You might be tempted to dismiss this as just plain wishful thinking, but did you really think of everything? For example…

As long as you can write to the terminal device, you can inject data into that shell's input. Under screen's default configuration on my machine:

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

This inserts ␛]lfoobar␛l in the shell's input stream. \ek is the control sequence that lets an application (or anything that can write to the terminal device) set the window title (see the “Naming windows” section in the screen manual), and \e[21t makes the terminal report its title on the application's standard input (screen doesn't document this sequence, but does implement it; you can find it under CSI Ps ; Ps ; Ps ; t in the xterm control sequences list. In fact, at least under screen 4.0.3, all control characters are stripped from the reported title, so the shell reads lfoobar (assuming ␛] is not bound to an editing command) and no newline. So the attacker can't actually execute a command that way, but can stuff a command like chmod u+s /bin/sh followed by a lot of spaces and a likely-looking prompt.

Screen implements several other similar risky control sequences, I don't know what their potentiality for vulnerabilities is. But hopefully by now you can see that the protection offered by screen session passwords is not that great. A dedicated security tool such as sudo is a lot less likely to have vulnerabilities.

  • +1 Excellent answer. Thanks for taking the time to explain it all. – Michael Mar 4 '11 at 21:46

The pipes created by screen are only accessible by the owner, therefore this shouldn't be a security issue.

  • 5
    You used "are" in the first part of your sentence where you probably meant "should be". Let's not get into the habit of making assumptions. – Shadur Mar 4 '11 at 15:58
  • 1
    Uh? The pipes created by screen ARE only accessible by the owner (if you don't manually chmod them). – Let_Me_Be Mar 4 '11 at 18:05

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.