Re: lynx-dev (forw) Possible buffer overflows in Lynx?

[T.E.Dickey]

> 
> On Mon, 28 Feb 100, T.E.Dickey wrote: 
> [kw:] 
> > > Sure there are buffer overflows.  Nobody has done a comprehensive audit.  
> >  
> > agreed (but we keep picking away at it). 
>  
> Yes, and things are a lot better than some versions ago. 
>  
> > > If one needs to put a bogus http_proxy like http://AAAAAAAAAAAAAAAAAAAA  
> > > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[add a couple thousand more] in  
> >  
> > I thought we fixed the places reported in this - last summer. 
>  
> Maybe I misunderstood what M. Zalewski meant. 

perhaps (but he said much the same thing last year - without examples such
as the one you show, I suspect he's just repeating himself).
  
> > > Fixed lenght buffers are still used in various places, without checking  
> > > always for overruns.  One place is HTTP.c, with things like  
> > >   sprintf(line, "Host: %s%c%c", host, CR,LF);  

this one's simple to fix (with a .* in the format).  I don't know why we
overlooked this module before (the files under src are a lot more work to
go through).

> > ok (always more to find). 
>  
> Actually, I think this is the one he found w.r.t. proxies. 
> This would only happen if some form of proxy or gateway is used, 
> since otherwise impossibly long hostnames are already rejected in 
> valid_hostname(). 
>  
> Other unchecked calls in HTTP.c involving 'line' (see 'language', 
> 'pref_charset') are less dangerous, since the information can come 
> only from lynx.cfg or .lynxrc or the Options screen (you get what you 
> deserve) not from any old Web page. 
>  
> I suggest to just skip sending those headers if the contents would be too 
> long, rather than using malloc'ed strings everywhere.  It seems wasteful 

...and rather than truncate them?

> to add more malloc calls and slow down every access, just for handling 
> a potential overlong header correctly.  None of those headers are required 
> by the protocol anyway, and if the line doesn't fit in line[INIT_LINE_SIZE] 
> it is obviously bogus.  So there is no point to waste more network packets 
> for sending it. 
>  
> > > One thing though: LY_MAXPATH may be way too small for some systems.  
> > > It is defined to 256 in HTUtils.h.  Shouldn't this match the system's  
> > > PATH_MAX (or MAXPATHLEN) (+ 1 ?) instead?   
> >  
> > PATH_MAX is technically a minimum - the system declares that it can support 
> > pathnames at least that long. 
>  
> But should we use it? 

it's better than nothing (at least it highlights places in the code that
assume they're big enough to hold a pathname).
  
> It would be better to check all strcpy etc. calls that involve fixed 
> LY_MAXPATH buffers, but I think there are still a lot of them. 

there's a lot - but when I last went looking for problems, the ones I saw
were all copying from one buffer to another of the same size (it's the
ones I overlooked that I'm interested in, such as HTTP.c).
  
>  
>           Klaus 
>  


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey