This is an HTML version of a news posting first sent out on the 2nd of September 1997.
Recent security incidents
There has recently been a security breach of two SGI systems in a University Department. The initial means of access was the use of the SGI default passwordless "
This seems like as good a time as any to request that every system administrator of every Unix system within the University and its related institutions performs a test for passwordless accounts. Please remember to check the shadow files on those systems that use shadow passwords.
Silicon Graphics use a passwordless "
lp" account for one of their implementations of network printing. This is designed to let anyone print to or through your system, but in practice lets anyone log in to your system. The easiest fix-up for this hole is to give "
lp" a password (or put an asterisk in the password entry) and then put a
.rhosts file in lp's home directory on your system containing the list of SGI systems you want to be able to print through your system. If you don't believe you are providing a print service (the usual state of affairs) then do not create this file. If you are using the BSD style of printing then you don't need this file either.
How to check for passwordless accounts
The following basic guidelines describe how to check for passwordless accounts. They may not cope with all combinations of systems; system administrators who need further guidance should contact their Departmental Computer Officer in the first instance.
On a basic (non-shadowed) system check the file
/etc/passwd. This file consists of one line per user with each line containing a series of entries separated by colons.
The second entry ("
B0Q83XyDczIdm") is the encrypted password. A passwordless account has the two colons adjacent. For example:
lp::9:9:Print Spooler Owner:/var/spool/lp:/bin/sh
is the passwordless "
lp" account on an SGI. If there is anything other than a 13-character sequence between that pair of colons then either the account has been locked so that no password will ever work (an asterisk is the traditional character for this rôle) or your system is running shadow passwords and you need to check another file.
On most modern shadow implementations there is an "
x" in the place of the encrypted password:
and on Solaris 1 (SunOS 4) systems, it looks like this:
You should then check the shadow password file. On most modern systems it is called
/etc/shadow but on Solaris 1 it is called
/etc/security/passwd.adjunct. The syntax of these files varies more from system to system, but typically each line starts with the userid and the encrypted password (separated by colons). This second entry should not be blank. However, later entries typically are blank. (These are reserved for password expiry and change information.)