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.