TUCoPS :: HP/UX :: man9.htm

Vulnerability
 man
Affected
 HPUX 10.20 and 11.00 and probably other revs
Description
 Jason Axley found following. The 'man' command potentially
 allows attackers to overwrite any arbitrary file on the system
 via symlink bugs.
 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. Jason 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!
 To 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.
Solution
 Patch is forthcoming soon.
 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!).