Original release date: April 23, 2001
Last revised: July 21, 2001
A complete revision history is at the end of this file.
Confirmed on Red Hat 6.1, 6.2 and 7.0
Low
The default installation does not assign a shell for most non-user accounts (e.g. nobody, bin). If no shell is specified for an account, the shell defaults to /bin/sh.
If no shell is specified for an account in the /etc/passwd file, the shell defaults to /bin/sh. The default installation of affected systems does not specify a shell for most non-user accounts (e.g. nobody, bin), granting these accounts higher privilege than may be desired.
A valid shell is not enough for login, and most of these accounts are set to prevent password authentication. Also, most exploits require that a shell be specified within the payload of an attack and are not dependant on the shell assigned by /etc/passwd. This does, however, violate the standard Rule of Least Privilege.
The difference between an account with no specified shell and one set to a shell that prevents login can be seen in the Demonstration section.
Additionally, the default installation of /etc/shells does not contain a shell such as /bin/false which would deny login.
Red Hat was contacted about this in June 2000 and has elected not to fix this problem.
On its own, this does not pose a significant threat. However, very few of these accounts require a shell, so there is no reason to grant this extra privilege. This may violate security policies for granting the minimum privileges necessary to accomplish a task.
There is potential for a privilege escalation attack. For example, a SUID program which properly handles root privileges but has a flaw in the way it handles other system accounts.
On July 21, 2001, an advisory by SSH Communications was posted to VulnWatch regarding an authentication error which allowed an attacker to log in under any account with a password shorter than 2 characters (e.g., !!). The optional RedHat user 'postgres' (Installed with the postgres SQL server) has the default password '!!' and is assigned the shell '/bin/bash'.
As I pointed out in my response, the impact of this vulnerability could have been reduced had an appropriate shell been assigned to this user by default.
The solution would be to assign these accounts a false shell which will not permit login, such as /bin/false. This shell could be added to /etc/shells for use with chsh.
[root@roto-router /root]# grep "xfs" /etc/passwd
xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false
[root@roto-router /root]# su xfs
[root@roto-router /root]#
A demonstration of how the SSH 3.0.0 vulnerability is affected by this issue:
[root@shiva /root]# cat /etc/shadow | grep "postgres"
postgres:!!:11515:0:99999:7:::
[root@shiva /root]# ssh -l postgres localhost
postgres's password: <Null Password Entered>
Authentication successful.
Last login: Sat Jul 21 2001 09:09:21 -0700 from localhost
bash$ logout
Connection to localhost closed.
[root@shiva /root]# cat /etc/passwd | grep postgres
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
With an appropriate shell assigned, the impact of this vulnerability is reduced:
[root@shiva /root]# chsh -s /bin/false postgres
Changing shell for postgres.
Warning: "/bin/false" is not listed in /etc/shells
Shell changed.
[root@shiva /root]# cat /etc/passwd | grep postgres
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/false
[root@shiva /root]# ssh -l postgres localhost
postgres's password: <Null Password Entered>
Authentication successful.
Last login: Sat Jul 21 2001 09:11:01 -0700 from localhost
Connection to localhost closed.
[root@shiva /root]#
Credit goes to Simson Garfinkel and Gene Spafford who pointed out the default shell in their book "Practical UNIX and Internet Security; 2nd Edition".
Copyright 2001 Blake R. Swopes.