[comp.unix.ultrix] UNOFFICIAL SECURITY NOTIFICATION

avolio@decuac.dec.com (Frederick M. Avolio) (10/18/89)

[I apologize if anyone gets two postings of this.  One got away with the
wrong Subject: line.]

I am not making a public statement from Digital.  I am not acting in any
capacity except as that of a fellow ULTRIX user/system manager with a 
system on the Internet.

A report has reached me that a couple of ULTRIX machines in the New England
area have been infultrated -- how is not yet known.  The intruder has
replaced the login program with another which seems to gather UID's
(multiplied by some factor) and passwords.  It is not known if this is an
outside attacker or someone with accounts on the systems in question.

It is not known how the illegal entries are made but I suspect that one
possibility is the publicized bug in /usr/bin/login which will allow
any user to get root access.   To check to see if you login is intact
you can use the fverify routine (of course, if fverify has been modified
you're in deep sneakers, eh?).   You can issue the following
command from the root directory as root:

    % grep /usr/bin/login /usr/etc/subsets/ULTBASE030.inv | fverify -n 

the login record on my ULTRIX machine from that file (in case you want
to check it) is:

0000	68608	27379	0	0	104755	11/15/88	030	f	./usr/bin/login	none	ULTBASE030

You should (as was indicated in this newsgroup and via letters from Digital
(I believe):

	chmod 4750 /usr/bin/login

on ULTRIX 3.0 systems.

Fred

avolio@decuac.DEC.COM (Frederick M. Avolio) (10/18/89)

More unoffcial suggested steps (these from a CERT Advisory):

	1) Check for a bogus /usr/bin/login.  The sum program reports:
		27379    67	for VAX/Ultrix 3.0

	2) Check for a bogus /usr/etc/telnetd.  The sum program reports:
		23552    47	for VAX/Ultrix 3.0

	3) Look for .savacct in either /usr/etc or in users' directories.
	   This may be the file that the new login program creates.  It
	   could have a different name on your system.

	4) Upgrade to Ultrix 3.1 ASAP.

	5) Monitor accounts for users having passwords that can be found in
	   the /usr/dict/words file or have simple passwords like a persons
	   name or their account name.

	6) Search through the file system for programs that are setuid root.

	7) Disable or modify the tftpd program so that anonymous access to
	   the file system is prevented.

mogul@decwrl.dec.com (Jeffrey Mogul) (10/21/89)

In article <2781@decuac.DEC.COM> avolio@decuac.DEC.COM (Frederick M. Avolio) writes:
>More unoffcial suggested steps (these from a CERT Advisory):
>
>	7) Disable or modify the tftpd program so that anonymous access to
>	   the file system is prevented.

Note that people who are using the Ultrix 3.0 (or later) version of
"tftpd" should be able to use the "-r" (restricted root) flag to limit
access to a subtree of the file system.  This is essentially the same
mechanism as is supported by the ftpd server to limit anonymous ftp access.
Unfortunately, I believe that some people didn't receive a properly
updated manual page for tftpd; the syntax to use in /etc/inetd.conf is:

tftp    dgram   udp     nowait  /usr/etc/tftpd  tftpd -r /local/bootfiles

for example (you can see that we only use TFTP for bootloading).

-Jeff