I. Description



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.





II. Impact



A malicious user with access to the same machine as other Lynx users

may be able to cause another user's Lynx process to overwrite another

file.  It may also be possible to replace the contents of a downloaded

file with a file other than the one the user downloaded, or to cause

the user to print a file other than the one selected for printing.





III.  Workarounds



A workaround for Lynx 2.7.1 is described in the "solutions" section

below.





IV.  Solutions



There are several ways to solve this problem.



A. 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 solutions below.



B. 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/





The FOTEMODS patches avoid any pre-existing filenames for new temporary

files, thus skipping any symbolic link which may have been created with

an upcoming temporary filename.  These patches also allow the administrator

or user to define TEMP_SPACE (or the LYNX_TEMP_SPACE environment variable)

as "/tmp/$USER" (for example) for pre-existing directories that correspond

to accounts' usernames and have protections/ACLs set for access only by

the appropriate users.



This patch set also does chmod(600) for temporary files which Lynx

creates, but the account should be set up with an equivalent umask

before invoking Lynx.



C. One other solution (a source code patch) for this problem, by Klaus

   Weide, can be found at:

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

   However, this patch should be considered "alpha" quality code, and

   its author is not supporting it at this time.





The next release of Lynx will eliminate this vulnerability.  Interested

parties should subscribe to and read the LYNX-DEV mailing list

(send mail to majordomo@sig.net with "subscribe lynx-dev" as the

body) for information about this release.





V. Contact information



If you believe you have found a security problem with the current

version of Lynx, we urge you to forward it to the LYNX-DEV

mailing list at .



The LYNX-DEV mailing list (with further information about this

vulnerability) is archived at:

     http://www.flora.org/lynx-dev/



Lynx security information is available at:

     http://www.crl.com/~subir/lynx/security.html



General information about Lynx is available at:

     http://lynx.browser.org/



On-line help and documentation about Lynx is available using the

(h)elp command. More help is available in the source distribution.

Should your questions not be answered by these means, further

questions may be directed to .



Please don't contact Lynx developers personally about Lynx-related

issues; please use either the mailing list or the "help" addresses

given above.