Re: New Netscape bug (in version 1.12)

[jsw@neon.netscape.com (Jeff Weinstein)]

In article <199510040204.WAA22162@clark.net>, rjc@clark.net (Ray Cromwell) writes:
> > In article <DFv6uo.4so@sgi.sgi.com>, Ray Cromwell <rjc@clark.net> writes:
> > 
> > > This bug doesn't seem to crash Netscape, instead, it crashes my XServer
> > > as soon as the mail window pops op. I'm too tired right now to try to
> > > analyze it, but it might be another stack bug, this time, in the X
> > > libraries because Netscape isn't doing any sanity checking.
> > 
> > This is a bug in your X server, not in netscape.  The X server should
> > never crash no matter what you send to it.
> 
>   That's true, but it is also true that Netscape should also be
> performing some sanity checking on input rather than relying on 
> the supporting libraries to be secure. Remember, a hole is a hole.
> The last sendmail bug was a buffer overflow in syslog, however,
> sendmail still got patched to do bounds checking on the strings
> it was passing to syslog. 
> 
>   It looks like this is only bug on BSDI2.0/XAccel, and NT3.5/NS1.1. But
> is it wise for netscape to be sending 10,000 character strings to GUI
> functions anyway? 

  While I agree that we should probably truncate this string to something
smaller than 10000 characters(I've already filed a bug on it here), it
is perfectly legal X protocol to send 10,000 characters to the X server.
How do I decide what is too long?  For example, when tracking down buffer
overflow problems for the security patch, we found an undocumented
static buffer limit of 64 bytes for the hostname passed to gethostbyname()
on IRIX.  Before we stumbled across this problem, we had a discussion
about what length we should truncate host names to.  People thought
that 128 characters was a reasonable limit, but it turned out that it
was too long.

  If the X server crash is what I think it is, it could still be hit
if we limit the string length, depending on the user's font selections
in their .Xdefaults.

  The fact is that if we are passing documented legal values into X,
unix, windows, or some other system software, we may still tickle
some bug in the system.  We can't test against every patch level of
every piece of software that our code may run against.  If that code
crashes its a bug in that code, and there is little we can do about
it other than try to play by the documented rules.

  That said, there are probably still bugs in Netscape that will
cause it to crash.  We took care to try to find all such bugs that
occured on the stack, which could be used to insert code and
jump to it.  That was the best we could do in the timeframe of
the security patch.  For 2.0 we are doing complete code reviews
to look for any sort of overflows, stack or not, as well as other
latent bugs.  We are also beefing up our QA to try to find more
of these types of bugs.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.