lynx-dev
[Top][All Lists]
Advanced

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

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


From: Klaus Weide
Subject: Re: lynx-dev (forw) Possible buffer overflows in Lynx?
Date: Tue, 29 Feb 2000 13:21:48 -0600 (CST)

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.

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


          Klaus


reply via email to

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