Bypassing the command/script specified in /etc/passwd

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:

1. Log in via the GUI as games, without password.
2. Right-click to bring up the root menu.
3. Start a dbxtool.
4. setenv SHELL /bin/sh
5. (Optional) setenv HOME /
6. Start a shell with !
7. 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.

You cannot bypass the script execution. This is your login shell, and will be started every time you login. And as a login shell, will log you off every time it ends. But you can use quirks, bugs and inconsistencies on the login shell to escape.

One thing you could do is to escape to a shell using any option on the menu. If the menu lets you start vim, less, more or some other commands, you can theoretically break free. If the sysadmin is experienced, those commands will use their restricted versions and will not work.

I remember a wargame challenge where there was a similar case - the shell pointed to something that simply printed some output using the more command, then terminated the session. However, since more features a built-in text editor (in this particular case it was vi), it was enough to resize the terminal window from which you were connecting so that more is activated, then use it to escape the shell.

So, the answer depends on what your script does. Check the man pages for each of the commands you are running to avoid a vulnerability.