Original release date: April 23, 2001
Last revised: July 21, 2001

A complete revision history is at the end of this file.

Systems Affected

Confirmed on Red Hat 6.1, 6.2 and 7.0

Severity

Low

Overview

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.

I. Description

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.

II. Impact

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.

III. Solution

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.

IV. Demonstration

[root@roto-router /root]# grep “nobody” /etc/passwd
nobody:x:99:99:Nobody:/:
[root@roto-router /root]# su nobody
bash$

[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]#

V. Credit

Credit goes to Simson Garfinkel and Gene Spafford who pointed out the default shell in their book “Practical UNIX and Internet Security; 2nd Edition”.

 

BhodiSoft Contact Information

Email:

 

[email protected]

Getting security information

BhodiSoft publications and other security information are available from our web sitehttps://www.bhodisoft.com/

Copyright 2001 Blake R. Swopes.

---

Revision History

April 23, 2001: Initial Release
Posted to BUGTRAQ: April 23, 2001
May 12, 2001: Edited Discussion and Impact sections. Fixed formatting errors.
July 21, 2001: Added info on SSH 3.0.0 vulnerability to Impact and Demonstration sections.