Re: LYNX-DEV fix-v2 temp code.

[Jonathan Sergent]

 ] On Wed, 16 Jul 1997, Jonathan Sergent wrote:
 ] > Anyone willing to look at it?

 ] I did (again), but not very carefully.  Would prefer that I not be
 ] the only one who looks at it.  There seemed to be other people with
 ] interest (and strong opinions) on this on the list, a while ago.

That's what I was curious about as well; I was under the impression
that there were others who were interested.  Thanks for trying out
that last patch, I didn't have time to test it too much (obviously).

I did test it some to make sure it got rid of the file-creation
attack.  I'll fiddle with trying to exploit the race condition with
the existing code if I get enough time, mainly to make sure that the
same thing doesn't work on my code... some "black box testing", as 
it were.

 ] I agree that with the previous (Fote's) code there seems to be still a
 ] small (but not zero-length) time between the checking and the opening
 ] where an attack could succeed.  And you are tryin to fix that.

I'm more concerned with the fact that it can't detect symlinks pointing
to nowhere, and will therefore create temp files in places other than
TEMP_SPACE if the symlinks are sitting there before the program starts
or are placed there before it opens the temp file.  The only way
around this without creating another race condition problem is to use
open(fnam, O_CREAT|O_RDWR|O_EXCL{, mode})... using lstat or anything
else is problematic.

File-creation can be a problem if the file to be created is something
like .rhosts and the thing being written has the right contents.

But the race condition is important, and several programs (notable
mail user agents) have had updates or CERT advisories due to the race
problem within the last year.  They generally used mktemp() and only
needed to switch to mkstemp() or something with the same properties,
but Lynx doesn't have that luxury.

There are automated ways of exploiting these race conditions, which 
you can find in BUGTRAQ archives if you look for the discussions of
the race conditions in the mail user agents.  They don't always work 
but after a few tries they will.  The user under attack gets no 
indication that it's going on, either.

*snip compiler warnings, will fix*

 ] 3.) The more direct cause of the core dump seems to be the use of
 ] statusline() while LYCursesON is FALSE.  I am not sure what the best
 ] way is for warning messages which may occur with LYCursesON TRUE or FALSE.
 ] There doesn't seem to be one function that is designed for both cases.
 ] So I guess you have to test for it.  See the code which generates the
 ] "guessing..." messages in LYUtils.c for example.
 ] 
 ] Your turn...

I was aware of that with the first patch I posted, and asked for 
guidance as to the right way to do it.  I'll look at the guessing
message code...

The next time I work on this (Sunday probably) I'll do it on the
lynx-current (lynx-ac?  lots more than autoconf these days) code
set so that I can stop pestering poor Fote.  

The quality of these patches is going up I hope as I get more used to 
the Lynx way of doing things.  This may not be a good thing for any 
other programming projects I might take up, though.



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