Re: lynx-dev lynx 2.8.x - 'special URLs' anti-spoofing protection is weak

[Klaus Weide]

On Mon, 22 Nov 1999, T.E.Dickey wrote:

> > 
> > On Mon, 22 Nov 1999, T.E.Dickey wrote: 
> >  
> > > it's a followup to a posting where he criticizes _all_ of the special 
> > > urls.  
> >  
> > Yes, there are two nasties that he found.  And he's right about both of 
> > them. 

Actually, I forgot about the third nasty he finds, buffer overruns:

>>  Now, the most interesting thing - by putting funny 'preffered charset',
>> 'preffered language' and 'user agent' fields into form (I've tried with
>> >64kB of 'A's, but probably it could be much smaller), you'll cause

There doesn't seem to be a problem, as of current dev code, *in the Forms
Menu Code* itself.  But there is in HTTP.c.

> agreed - but singling out the options form isn't.

I think it is.  I don't see something really sensitive[*] depending on
flawed checks for any of the others.  Maybe there is, but it hasn't
been shown.

[*] As opposed to: just annoying.  (E.g.: give a document the
<TITLE>History Page</TITLE>, and you can't invoke the real History
Page while viewing that page...)

> > 1a) Well but how many of those title comparisons are really in some way 
> > "security" relevant?  I.e. what exactly depends on the right outcome? 
> 
> he's saying that all of them are (of course).

So does your "(of course)" mean that you agree with him?  Or the opposite?
:)

> I don't see why the same rules for validating the internal pages would not
> apply equally to all of them.  

It's not all about validation or permission checking.  Sometimes it's just
"are we already showing the HISTORY/VLINKS/INFO/... page? - then let's get out".

> (but the code that checks titles is repeated in several places - my
> inclination would be to consolidate it, and then fix the holes)

All checks on title should be replaced by checks on address, where it
makes sense.  That's probably all of them but might exclude some
checks (maybe Help page titles?) that are purely informational (if
such exist).

I'm sure the only reason it hasn't been done is 'cause there are so many...
and no general way to "register" special temp files.  But the most
important places (== handlers of special URLs) already *do* keep track of
the valid "file:" URL, in one way or another (see dired, see LYDownload.c,
see LYList.c), so that it can be used for page address checking.


> > Which details don't apply to 2.8.2? 
> 
> he implies that all files in /tmp are automatically insecure.

If you mean "(this solution not for the first time brings several
security problems, but probably is quite convenient)", that looks just
like completely generic speculation & general theory.

   Klaus