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
␛]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
␛] 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.