Previously I wrote about two "bugs" with GNU Screen.

Now I discover, via a customer, that one of the servers I setup had allowed shell access when it should have been prohibited. A potentially serious security hole in this context.

Here is an example, with this small .screenrc file:

#
#  Normally "ctrl-a c" would open a new "window".
#
#  We wish to prohibit that
#
bind c

Start GNU screen. Press "Ctrl-a c" nothing happens. All looks well, you've denied a new window! If you'd setup a shell in /etc/passwd to point to a wrapper which invoked GNU Screen with this configuration file you'd be fine, right?

Actually not. Try pressing "Ctrl-a" and whilst those two keys are held down press and release "c". Joy. New window created. Even though it shouldn't be.

Update - Turns out I'm stupid "ctrl-a c" is the same as "ctrl-a ctrl-c" by default. I didn't add "bind ^c" appropriately. My bad.

For reference if you want to stop shell creation and you invoke screen as a login shell as a wrapper for other things then you must unbind a lot of builtins. eg. "bind :". You should then set:

shell /bin/false

Only then will you be secure. Probably.

Thankfully this doesn't affect the Xen shell.

Tags: false alarm, gnu screen, rants, screen | No comments