COMMAND

    man

SYSTEMS AFFECTED

    Linux/SunOS

PROBLEM

    Thomas Fischbacher noticed a problem with the man system  (version
    2.3.10) on Linux box: /usr/man contains the .gz'd man pages:

    (from /usr/man/man1:)

    -rw-r--r--   1 root     root         1684 Sep 28  1995 cp.1.gz
    -rw-r--r--   1 root     root         4063 Dec 29  1995 cpio.1.gz
    -rw-r--r--   1 root     root           42 Oct 17  1996 cpp.1.gz

    When  executing  man,  a  temporary  file containing the un-zipped
    manpage is created in /tmp.   The name of the tmp-file usually  is
    "zman<PID>aaa", e.g. "zman10849aaa". This can be exploited with  a
    simple symlink attack:

        perl -e 'for($i=8000;$i<12000;$i++){`ln -s /root/.rhosts /tmp/zman${i}aaa`;}'

    So when  root executes  man here  and the  pid of  the man process
    falls in the  range 8000-11999... you  know the rest.   In general
    passive  attacks  like  this  can  be  used to overwrite arbitrary
    files on the system by making  symlinks if and only if root  isn't
    paying attention to what he is doing.

    "d" added how pretty much the same is with unformatted 'roff pages
    on   suns   with   variously   different   filenames;  sunos  uses
    /tmp/man{pid}, solaris /tmp/mpa+cruft, etc.

SOLUTION

    Perhaps only  a another  reason to  use catman.   man version 1.4j
    (from typing  man -?)  doesn't exhibit  this problem.   It  writes
    directly to var/catman  and doesn't use  /tmp for anything.   Note
    that  it  will  depend  on  exactly  HOW  the  temporary names are
    generated.  NetBSD uses a similar formula for the name (man.XXXX),
    but it's gaurenteed to be unique (mkstemp call) - so if you create
    the sym-links,  it'll just  name it  something else.   The use  of
    mkstemp over mktemp is also  supposed to avoide the race  condtion
    between generating the file name and opening it for writing.

    Kernel patch which  prevents users from  making symlinks to  files
    which they  don't own  would be  a option.   It solves  this and a
    host of other symlink problems.