Re: LYNX-DEV fix-v2 temp code.

[Foteos Macrides]

Bela Lubkin <address@hidden> wrote:
>Foteos Macrides wrote:
>
>>      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. :) :)
>
>It has been repeatedly proven that such windows, no matter how
>miniscule, *are* exploitable.  See, for instance, old CERT alerts about
>Sun's sendmail local delivery agent.  It's good that the window has been
>narrowed, but Jonathan is correct to be trying to close it completely.
>
>The final implementation should have the characteristics that on systems
>with appropriate kernel/library support (at least one of 3-argument
>open(), fchmod(), or sticky directories), it is completely secure; and
>on impoverished systems, the window is as narrow as possible.  From what
>you're saying, the current fotemods code has a window on all systems.
>That's unacceptable from a security standpoint.  A narrow window just
>means that the attacker has to spend a bit more time trying to catch it.

        They depend on having set a /tmp/$USER with mode 700 and an
appropriate umask before invoking Lynx, as explained in the distribution
(and on Lynx skipping any pre-existing files).  I realize that you have a
slow PPP connection from Russia and are discussing this in the abstract,
without having actually examined the modifications.  It anyone implements
those security measures and demonstrates a breach -- under realistic
conditions -- please let me know.  Obviously, others can continue
discussing this in the abstract, but at this point I personally plan to
devote my spare time to other matters, OK?   Also please remember that
the fotemods code set is the code I'm personally using, made available
(thanks to Scott) in compliance with the GNU GPL, and is not a development
code set (though Klaus has incorparated most of my mods into the actual
development code set).  When these security matters came up, the fotemods
were at a stable point, and I offered to package it up as a version to
go with a CERT bulletin, but there were no comments on that, for quite
some time, so I moved on to making more mods (one or two comments were
made latter, after I had moved on, and not in a manner which indicated
consensus, which *is* necessary for "formal" releases)  The CERT bulletin
ended up pointing to the fotemods, by that time a moving target again,
and that is not going to help sites or organizations which require a
formal release for an upgrade, as you pointed out yourself w.r.t. SCO.
Such is life, I guess...

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