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

[Klaus Weide]

On Thu, 8 May 1997, Scott McGee (Personal) wrote:

> I can see people with space problems finding it difficult to use lynx if it
> puts temp files under $HOME. Maybe the thing to do is to leave temp as is,
> but within temp create a directory (with appropriate checks to enusre it is
> not there already) with owner only permissions, then use that directory for
> all temp files. We create it, so nobody can get in ahead of us, and we set
> permission so that nobody can get in after creation. On exit, we just do a
> recursive deletion of that directory.
>
> This way, we make use of whatever directory the installer (individual user
> or sysadmin) feels is most appropriate for temp space, but provide security
> for it too.

That is what the script does which I posted.  Of course this could also
be put in the Lynx code.  But having it done by an external script makes
it easier to configure the name of the subdir or just turn use of subdirs
off (it is not needed in many cases, for example if $LYNX_TEMP_SPACE
already points to a place under $HOME), without having to invent new
configuration options and syntax (which many installers would miss
anyway).

Note (as Alan Cox pointed out) that all this still depends on the "sticky
bit" being set if the (parent) tmp directory is shared.  There doesn't
seem to be a way around that.  (Except from extensive restructuring of
how Lynx handles its files, using mkstemp() or similar.  Which likely
wouldn't work on all systems anyway and introduce new problems, especially
if done in a hurry.  Maybe I am too pessimistic here - well I'd be
delighted to be proven wrong.).
 
> I missed the talk of a CERT advisory, but if they are going to issue such,

AFAIK this is just a (maybe informed) guess.

This problem is not one specific to Lynx (although Lynx makes it more
visible than other programs).  Maybe we are taking ourselves too
important if we expect a CERT advisory specifically dedicated to Lynx...

> I agree that we should get a fix in place, release the fixed version as
> either 2.7.2 or 2.8 (depending on the code base and what Fote feels about
> 2.7.2), and let the CERT people announce the new version along with the
> advisory.

CERT advisories do not _have to_ have, in their section titled

III. Solution,

   "Upgrade to the latest release. [...]"

They could just as well make people aware of the mechanism already
existing in all Lynx version (AFAIK) for setting a directory for temp
files, give some detailed instructions on how to set LYNX_TEMP_SPACE
(possibly in a wrapper script) and use "sticky", and save them from
feeling they have to install a new version.
(No, I have no idea how to "make them say" anything.)

I don't think "You have to upgrade" is sending a more possible 'marketing'
message than "It's already there, here's how to use it".
I think the first is more likely to lead into making Lynx unavailable
than the latter.  ("Ah, we have to compile and test a new binary.  
Hmm, no time to deal with it now, let's just disable it `for now'...")

Especially when a new version to upgrade to isn't there.  It is very
unrealistic to expect something that would deserve to be an "offical"
replacement version in "under a week or so" based on the current
development code.  "Something" could be done based on current fotemods
(that depends on Fote, of course) or even just plain 2.7.1, but
(1) rushing out something which hasn't had the amount of testing which other
    Lynx versions had before a release seems like a bad idea,
(2) *I* still don't know what that "something" is that would
    (a) be generally acceptable (forcing temp dirs under $HOME isn't, IMHO),
    (b) actually solve the problem without relying on other things 
        (sticky bit or similar).

> This actually gets us several things. It lets people know that Lynx IS under
> current development. It further tells them that we are security concious and
> that Lynx reflects that. It buys us free advertising of the latest version.
> And hopefully, it will get a "modern" version (post GPL and the move away
> from UKANS) onto sites that may not bother otherwise. (The latter also helps
> by moving more people to versions of Lynx that point at lynx.browser.org and
> other "current" sources of help and information.)

We seem to disagree about the *positive* "free advertising" effect of CERT
advisories.  But of course I may be wrong.

   Klasu

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