COMMAND

    kerneld / request-route

SYSTEMS AFFECTED

    Linux RedHat (all kerneld/request-route versions)

PROBLEM

    Credit goes to Nicolas Dubee for following.  It was tested  tested
    on 2.0.30/Redhat  4.1 and  Redhat 3.0.3.   Preoblems appears  with
    lock files, symlinks.  When kerneld/request-route are set up,  any
    user can overwrite any file on the system.

    kerneld(1) is a daemon that "performs kernel action in user space"
    (see  man  page).   request-route  is  a  shell script that should
    launch  pppd  and  allocate  a  network  route  'on-the-fly'  when
    kerneld receives a  'request-route' kernel message.   It can  also
    be configured to use other network interfaces.

    request-route uses  a lockfile  named /tmp/request-route  where it
    writes its  pid in.   Unfortunatly, request-route  does not  check
    wether  this  lockfile  already  exists,  will follow symlinks and
    will create new files mode 600...

    One can  then create/write  to any  file on  the affected  system,
    regardless of permissions.

    An attacker  would create  a symlink  from the  /tmp/request-route
    file to any file on the  system. He would then for example  telnet
    to  a  host,  resulting  in  a  request-route  kernel message. The
    /sbin/request-route  would  then  be  executed and would overwrite
    the file at the end of the symlink.

SOLUTION

    Linux 2.1.x is not affected. Linux dumped this feature.

    /sbin/request-route is a  script. So, the  script can be  fixed to
    check for  the lock  file, or  whatever other  security check  are
    needed.  No need to just  go and remove before finding a  suitable
    solution. A simple solution would be to add a:

        set -o noclobber

    In the script, right here:

        sleep 60 &
        sleepid=$!
--->    set -o noclobber
        echo $sleepid > $LOCK
        wait $sleepid

    Unfortunately this is still not enough.  The problem is that  many
    (if not  most) shells  do not  implement noclobber  in a race-free
    way,  but  even  if  they  do,  noclobber  still allows writing to
    device special files,  so a symlink  to /dev/hda will  be followed
    by the shell destroying your master boot record.

    If the script runs as root (as it is the case with request-route),
    it is enough to put the  lockfile in a directory writable only  by
    root.  Debian uses /var/run for the request-route lockfile.