HP Security vulnerability in the man command

[jason.axley () ATTWS COM (Jason Axley)]

Systems Affected:
HPUX 10.20 and 11.00 and probably other revs.

Short Description:
The 'man' command potentially allows attackers to overwrite any
arbitrary file on the system via symlink bugs.

I notified HP on 5-8-2000 and I've been told that a patch is forthcoming
soon.  No HP advisory has come out on this yet.

Problem Detailed Description:
The programmers of the 'man' command on various HPUX releases have made
several fatal mistakes that allow an attacker to trivially set a trap
that could result in any arbitrary file being overwritten on the system when
root runs the 'man' command.

Mistakes:
0) HP *still* insists on NOT setting the sticky bit on world-writeable
temporary directories (/tmp and /var/tmp) on default installs of HPUX.
This can be exploited to delete existing catXXXX and manXXXX files and
replace them with symlinks since anyone is free to delete any file from these
directories, regardless of file ownership.  This can also be used to play fun
race conditions in other exploits where a race exists between stat()ing
or creation of a file and the opening of that file.  This could
potentially be used here to watch /tmp for catXXXX and manXXXX file creation,
delete one of those files, and symlink it to the file you want overwritten
before the file is opened for writing and truncation.  Fortunately, the man
command is not setuid on HPUX or else normal users would be able to get root
without having to wait for root to run man.

1) man creates temporary files with predictable filenames in
world-writeable directories.  The two files are named catXXXX and
manXXXX where XXXX is the PID of the man process (highly predictable).

2) man blindly follows symlinks.

3) man explicitly opens the temp files with mode 666 and
ignores the existing umask.  I verified that this doesn't change the mode
of existing files to 666, but it allows for attackers to edit the tempfiles
and potentially insert harmful man commands that will get (like recent
Bugtraq discussions about malicious manpages).

4) man opens the tempfiles with O_TRUNC.  This means that when a file is
symlinked to, that file is blindly truncated.  This could lead to easy
denial-of-service if you want to trash the password file or a hard disk
device file.   This could also have bad effects on sane man program operation,
regardless of security, if a user runs man and leaves it running, then PIDs
are wrapped around and someone of higher privilege runs man and overwrites
your tempfiles!

Exploit:
Create ~65535 catXXXX or manXXXX symlinks in /tmp, pointing to the file you
want to overwrite (e.g. /etc/passwd).  Then wait.  When root runs man, the
file will be blindly overwritten with the formatted manpage contents (cat????)
or unformatted (man????) are written to the symlinked file.

Solutions:

For HP Admins:
You could create root-owned catXXXX and manXXXX files in /tmp AFTER
chmod'ing /tmp to 1777 to keep attackers from making the symlinks.

For HP and other programmers who have or will make similar mistakes:
0) Ensure that people verify that /tmp and /var/tmp have the sticky bit
set.  Also, ensure the sticky bit is set on by default in future releases
of HPUX!

1) Do not create tempfiles in world-writeable directories.  Or, use mkstemp()
or a similar function to generate unique, difficult to guess tempfilenames.
HPUX does not have an entropy source to draw from so this may not be a
bullet-proof solution.

2) Rewrite man to not follow symlinks by doing a secure stat of the file to
check if it is a symlink and error out if it is (security message to syslog
too would be nice).  Use lstat() (NOT stat()) to stat the file and be sure it
isn't a symlink.  Follow the example in the URL below to verify the file and
open it securely.

3) Rewrite man to honor the existing umask!  Don't explicitly create
world-writeable files.

4) Do not blindly use O_TRUNC when opening the tempfile.  The program should
error or try a different filename if the target exists.  Again, be aware of race
conditions when checking for file existence and then the subsequent open of
that file.  You should use O_CREAT and O_EXCL together to cause open to fail
if the target file already exists.  You should be using ftruncate() (available
on HPUX) to truncate the opened file (that you've securely opened, based on the
guidelines at the URL below) if you are sure that you aren't going to hose a
file in use or a system file (e.g. fix the symlink problem first!).  Again,
follow the example below to really do all of this correctly.

http://www.homeport.org/~adam/review.html has a great example of tempfile
opening that avoids these various pitfalls.

-Jason Axley

AT&T Wireless Services
IT Security
UNIX Security Operations Specialist