Assume there is a (probably unintentional) backdoor.
The default /etc/passwd
on Sun workstations of the early 1990s included an entry something like this:
games::0:0:games:/nopath:/bin/false
In other words, an account named 'games' with no password. Apparently the genius who came up with this idea had no imagination, and assigned it a uid and gid of zero (i.e. root and wheel). Generally, that was okay, as the home directory was meaningless and the shell was set to a program that always exited with failure. Furthermore, the default settings for any access by network -- telnet, rlogin, rcp, ftp -- were set to prevent access by any uid of zero. There was a separate passwd entry for root, with a properly-set set password, home directory, and shell.
This meant if you tried to log in as games, the following would happen:
- Logging in as games at the console would at first succeed, but then spawn the
/bin/false
shell, which would immediately exit.
- Using telnet or rlogin would outright deny the login. Even if it had succeeded, the
/bin/false
shell would immediately quit.
- FTP and scp don't use shells, but they were configured to deny access to uid zero, so you couldn't log in this way.
- A GUI login would start up the default GUI services, including a window manager, clock client, and a terminal. The latter would immediately exit because its child shell would immediately exit. So you would get an empty screen except for a clock. (More on this below...)
- If you really had to log in as root, you would either have to do that from the console, or first rlogin/telnet as another user on that machine and then
su root
. Either way uses the root passwd
entry rather than the games passwd
entry, and thus works they way root should work.
So the games account appeared to always fail, unless you did a GUI login. In that case, the only thing that appeared was the clock. However, you could right-click on the background to get a root menu, with a factory-provided list of programs that users would normally customize for themselves. (Customizing the menu didn't work for the games account; I don't remember exactly why.) You could try to bring up more terminal windows, which would all fail. There was a puzzle game (which may have been the impetus for the account in the first place). Another choice was to log out. And then there was the graphical debugging tool, dbxtool
.
dbxtool
was a graphical frontend to the dbx
symbolic debugger, similar to today's gdb
. Being uid zero, you could attach to and control any process on the system, although this was not useful because programs provided by Sun were compiled without symbols. You could launch a shell, but this would use your SHELL
environment variable, which was /bin/false
. However, you could also change environmental variables! This meant you could get a root shell by the following:
- Log in via the GUI as games, without password.
- Right-click to bring up the root menu.
- Start a
dbxtool
.
setenv SHELL /bin/sh
- (Optional)
setenv HOME /
- Start a shell with
!
- Because the terminal is not set, do
stty sane
Voila, root shell without password!
So, do not assume that a user can't escape out of an invalid shell.