lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV fix-v2 temp code.


From: Foteos Macrides
Subject: Re: LYNX-DEV fix-v2 temp code.
Date: Thu, 17 Jul 1997 22:56:44 -0500 (EST)

Klaus Weide <address@hidden> wrote:
>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.
>
>> The current FOTEMODS code doesn't avoid the race condition problem (it
>> is possible to create the symlink to the existing file after tempname()
>> but before the fopen to write on the file with another process.  It's
>> hard to get in there at the right time, but it's not impossible.)  And 
>> although it can avoid (but not prevent if it loses the race) overwriting
>> existing files through symlinks it does nothing about not creating new
>> files (through symlinks which don't point to existing files).  Having to
>> use "/tmp/$USER" directories is annoying.
>>                                 ^^^^^^^^
>> I really think we should seriously consider trying to get rid of those 
>> problems.  If you folks don't believe me on either of the above points 
>> I can put together a demonstration script of some sort but I'd rather 
>> not do that for hopefully obvious reasons.
>
>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.

        Just so there's no further confusion about all this...

        The CERT bulletins are worded as if setting a sticky bit is
a component of the security measures in the fotemods, e.g.:

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."

My understanding is that not all Unix systems have this feature.
Accordingly, I sought and added security measures which do not
depend on that feature.  This is a design principle from which
my "unhealthy obsession" with Lynx would never allow me to depart.

        Similarly, Lynx uses fopen() and not open() or creat() for
a variety of purposes, because open() with an internally set umask(),
and stat()/lstat() for anything more than checking whether you are dealing
with a file or directory, have not proven reliable across Unix flavors
which Lynx seeks to support.   If an autoconf determines that the
flavor cannot have HAVE_foo defined for a security measure that depends
on a change to open(), then that flavor is up the creek without a paddle,
My "unhealthy obsession" with Lynx would never allow me incorporate that
into the fotemods.  If Jonathan finds /tmp/$USER too annoying, he is
under no obligation to use the fotemods.

        As far as the non-zero length microseconds between when tempname()
returns a tentative filename and the fopen() is attempted, with /tmp/$USER
set mode 700, and then a chmod(600) being done within those microseconds,
I still feel that Jonathan is going overboard and should have gone home to
sleep instead of generating buggy patch after buggy patch for the fotemods
code set (or at least generate patches for a code set that might incorporate
them).  The communication between tempname() and the calling functions is
not via a slow PPP connection from Russia. :) :)

        ON CONSENSUS:
        
        "My dad always used to say:
                'Son, if your friends all decide to jump off the
                 Brooklyn bridge, does that mean ya gotta do it
                 too?'
         I still use that good bit of advice."
                -- John Travolta in Look Who's Talking

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]