lynx-dev lynx /tmp security

[Jonathan Sergent]

</LURK>

Bela wrote (several weeks ago):

 ] This path leads to madness.  Do not underestimate the power of the dark
 ] side.

:-)

 ] The objective is to create a new file.  The only safe ways to do that
 ] are:
 ] 
 ]   open(O_CREAT | O_EXCL | O_TRUNC)
 ]   optionally, if that fails EEXIST,
 ]     unlink
 ]     open(O_CREAT | O_EXCL | O_TRUNC)
 ]     repeat as many times as necessary, bounded to avoid infinite loop

Woo hoo.  That's it!

 ] Look, all of this code needs to be gone over by a security expert.  In
 ] reality, all of Lynx needs that treatment.  But even just focusing on
 ] the issue of internal temp files, you need an expert looking at this.  I
 ] claim to be at least a low-end expert in the field.  You have proposed
 ] and even implemented "fixes" several times which do not, in fact, fix
 ] the problems, and sometimes make them worse.  Please let me work this
 ] stuff out myself.

I know how you feel; was doing the same thing about a year ago (and 
then ran out of time due to work).

 ] It is apparent to me that securing Lynx against /tmp races is going to
 ] require a complete rewrite of all of its temp file routines.  I'm
 ] committing to that project.  I'm also extremely busy with my job, moving
 ] into a new house, etc.  So it might take a few weeks before I have it
 ] ready to be integrated.  Bear with me.

Was apparent to me last year when we did the CERT advisory which
somehow managed not to state that the only fix for these problems 
in the versions of Lynx which then existed was to set TEMP_SPACE 
to your home directory.  

Good luck in working on this.  I tried last year and gave up due to
lack of time.  Starting new project which will keep me really busy
so I won't have more time to hack on Lynx, but having spent a large 
number of hours of time thinking about how to do this on 2.7.x, I'd 
be more than happy to look over what you do.  I'm probably best 
described as a "low-level" expert as well.

Having considered the issue before in detail, I would really like
to look over what you do to see if I have anything to add to it 
(lest the hours I spent thinking of ways to work on this be lost).

I might be able to dig up the last patch I did way-back; not sure
where it is but if you're interested, I can find it.  It was a
tempname replacement plus changes to all of the places that used
temp files to use it and O_CREAT|O_EXCL.  It had rough edges and
it was to 2.7.1 IIRC.

Klaus had also done some preliminary work that also had rough edges.
(Just out of curiosity I fingered him -- showed a login in July, 
whereas it had said December for months; did anyone ever hear from
him?)

I scanned the lynx-dev archives briefly a few weeks ago and had 
gotten the impression that this had all been shored up this year 
and so I stopped feeling guilty for knowing it was so insecure and
leaving it that way.

The main issues that Lynx has are that it tries to (a) reuse existing
temp file and that (b) it renames (changes extensions on) temp files
without requesting a new name for them.  Neither of these issues is
particularly difficult to solve.  The first one is a non issue with 
sticky temp directories, and the other just requires that any time a
temp file is opened it is either (a) known to already exist [was 
created via (b) earlier] or (b) opened with O_CREAT,O_EXCL.  I don't 
think truncating existing files is ever desirable, but I might have
missed something.

It seems simple but every time I look at Lynx I get reminded that it
really is a very large program.  Such is the web...

One thing that TED had mentioned way back was something about two-
argument open.  Is that really a concern? (does Lynx run on anything 
that old anyway?)


-- 
Jonathan Sergent / address@hidden                         <LURK>