COMMAND

   lynx

SYSTEMS AFFECTED

    Systems running lynx

PROBLEM

    Lynx typically stores persistent  temporary files in /tmp  on Un*x
    systems.  The filenames Lynx chooses can be predicted, and another
    user on  the system  may be  able to  exploit a  race condition to
    replace the temporary  file with a  symbolic link or  with another
    file.

    Installed versions of  Lynx where a  directory writeable by  other
    users (such  as /tmp  on a  machine to  which multiple  users have
    access) is  used to  store files  during download  are vulnerable.
    This vulnerability can only be exploited by a user with access  to
    an account  on the  machine running  Lynx.   So, when  a lynx user
    D)ownloads a  file, a  temporary file  with a  predictable name is
    created to store the file  until it is completely downloaded.  The
    file is  /tmp/L*0TMP.html (the  extension is  .html regardless  of
    actual file type).  * is the  PID of Lynx,  and 0 is  the download
    number  (the  second  download  would  have  number 1, and so on).
    Lynx  doesn't  check  for  previous  existence  of  this file, and
    *will* write to  symlinks.  Any  local user can  create a symbolic
    link (or hard  link, for that  matter) with this  predictable name
    to one  of the  Lynx user's  files, and  when this user D)ownloads
    something,  his  file  will  be  overwritten  by  whatever  he was
    downloading.  If  the  attacker  has  some  sort of idea as to the
    content of the download (before the fact, obviously) he can  write
    arbitrary data to the victim's ~/.rhosts or other crucial file.

    Since there is usually a substantial time space between  downloads
    (in  an  average  Lynx  session),  an  attacker has enough time to
    investigate, and set up his/her  attack.  Credit for this  goes to
    fflush.

SOLUTION

    There are several  ways to solve  this problem. The  best solution
    to the problem is  to apply the FOTEMODS  patch set and to  ensure
    that /tmp/ on your system is a "sticky directory."

    If  you  cannot  apply  this  patch  set,  if your system does not
    support sticky directories, or if  you cannot make /tmp/ a  sticky
    directory, you must use one of the other solution.

    The  other  solution  to  this  problem  is  to change the setting
    of TEMP_SPACE  from the  default ("/tmp/")  to non-world-writeable
    directories.  To do this with unpatched Lynx version 2.7.1:

        1. Lynx  can  be  rebuilt  with  the  "#define TEMP_SPACE"  in
           lynx2-7-1/userdefs.h  changed  from  "/tmp"  to  point to a
           directory only writeable by the user executing Lynx.

        2. The LYNX_TEMP_SPACE environment variable may be set  before
           shell startup  files (.profile,  .cshrc, or  equivalent) or
           into the system profile (/etc/profile or equivalent).

    As  an  aid   to  allowing  Lynx   to  find  user-specific   temp.
    directories,  Lynx  2.7.1  will  replace  "~"  in  the temp. space
    allocation with the path to the user's home directory.

    Individual  users  may  also  set  the LYNX_TEMP_SPACE environment
    variable to  point to  another place  known to  be unwriteable  by
    other  users  (for  instance  a  subdirectory  of  the users' home
    directory, or a mode 0700 directory of a "sticky" /tmp).

    To do this with Lynx 2.7.1 with the FOTEMODS patch set applied:

        You  may  use  any  of  the  methods listed for "vanilla" Lynx
        2.7.1.   You   may  also   use  "$USER"   in  TEMP_SPACE   (or
        $LYNX_TEMP_SPACE) to  specify user-specific  temp. directories
        such as /tmp/$USER/.

    The FOTEMODS  patch set  includes the  changes described  above as
    well as other fixes and feature enhancements.  It can be found at:

        http://www.slcc.edu/lynx/fote/patches/

    One other  solution (a  source code  patch) for  this problem,  by
    Klaus Weide, can be found at:

        http://www.slcc.edu/lynx/klaus/temp/

    The next release of Lynx will eliminate this vulnerability.