Re: LYNX-DEV Re: ...vulnerability in Lynx...

[Jonathan Sergent]

First, sorry if I'm frustrating you; I think this is an important issue, 
though.  I'm replying not to you in particular but to anyone else who
was wondering the same thing.

 ] If a system is set up with a "sticky" temp directory, and lynx creates a
 ] subdirectory there with resonable permissions, can it use the current method
 ] of creating temp files without becoming a tool for hackers to compromise
 ] security?

Nope; this is the entire problem.  If there was, it would just be a short
addition to LYMain.c.

Here's what lynx would do if it tried to make a temp directory:

 (1) Come up with a temporary filename.
 (2) Check to see if there is a file/symlink/directory with that name.
 (3) If there is, 
     a.  come up with a new temporary filename.
     b.  return to (2).
 (4) Make a directory there.

Here's the problem:

If the attacker gets in between (2) and (4), he can make a symlink there,
and lynx will make the directory at the symlink target.

If the attacker made the symlink point to a (nonexistant) subdirectory of
a world-writeable directory, the directory which lynx made could then be
renamed and a surrogate directory could be created (with more symlinks to, 
say, /home/naiveusr/important_file).

mkstemp gets around this for normal files (i.e. not directories) by 
changing the above loop to read:

 (1) Come up with a temporary filename.
 (2) Make a file there if there is none.
 (3) If there isn't, go back to (1).

Step (2) is an atomic operation (i.e. it can't be split up, it's a
single system call) which looks like this in C:

     fd = open(something, O_EXCL | O_CREAT | O_RDWR, 0600)

mkstemp returns you the open fd, which points to your file regardless
of whether it's been unlinked or renamed.  If anything happens afterwards, 
you don't care, because you have the correct file open and it has the 
correct permissions.  In this way, mode 0777 temp directories are not 
a problem.

As far as I know, there is no way to do this for making a directory;
there is no equivalent of the O_EXCL flag with mkdir.  

I'm 99.724% sure about all of the above.

Why is there nothing like O_EXCL for mkdir?  My guess is: you can't 
overwrite a file with mkdir in any case, and when it was designed there 
was no such thing as a symlink, so there was no reason for such a flag.  
This also means that hardlinks are not a problem for mkdir; mkdir
would return an error [EEXIST] rather than making anything bad.  You
can't make a hardlink to a directory anyway with most systems, it's
awful dangerous.

The real solution is to redo the temporary file handling.  This is
what had to be done with the mail programs, etc. which put their temp
files in /tmp (but not good old MH, which uses ~/Mail/drafts/ ...).
I'm not convinced that is as painful as it's made out to be.  I'll have
a look at this all next week when I'm back home.


--jss.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;