Re: New Netscape bug (in version 1.12)
In article <DFv6uo.4so@sgi.sgi.com>, Ray Cromwell <rjc@clark.net> writes:
C'punks, I just got back from a vacation in Raleigh, and downloaded the new "fixed" Netscape 1.12. It took me about an hour, but I've discovered another bug and potential security hole. This one relates to mailto:.
The bug is as follows. Create a HTML file with a hyperlink containing the following URL
foo
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.
I need help testing this bug on other platforms. I have created a test page. Go to http://www.gl.umbc.edu/~rcromw1/crash.html to test.
This doesn't crash my X server (SGI Irix 6.2), so it's probably specific to XAccel. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com
In article <199510040204.WAA22162@clark.net>, Ray Cromwell <rjc@clark.net> writes:
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?
It's absolutely okay for netscape to send long character strings to the X server. In fact, all it's probably doing is putting long character strings into a Motif widget, which then sends them to the X server. This is also totally okay. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com
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? -Ray
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.
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.
Isn't there a resolver #define or something in limits.h called MAXHOSTNAMELEN ? Something like that? (Perhaps not, but that's what I recall..)
latent bugs. We are also beefing up our QA to try to find more of these types of bugs.
great! -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 An Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer@c2.org
-----BEGIN PGP SIGNED MESSAGE----- On Wed Oct 4 14:00:26 1995: you scribbled...
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.
Isn't there a resolver #define or something in limits.h called MAXHOSTNAMELEN ? Something like that? (Perhaps not, but that's what I recall..)
The DNS RFC specifies that the max hostname should be 255 characters, with a 63 character limit for each segment of the name (RFC1035, section 2.3.4.) - --> 2.3.4. Size limits - --> - --> Various objects and parameters in the DNS have size limits. They are - --> listed below. Some could be easily changed, others are more - --> fundamental. - --> - --> labels 63 octets or less - --> - --> names 255 octets or less But, some older systems (SunOS4, and IRIX, amongst others) have the MAXHSTNAMELEN defined as 64 characters, so this limits the max name to 64. Solaris2 has MAXHOSTNAMELEN defined to 255 characters. (the define is in sys/param.h for sunos and solaris). just a point of interest... ...alex... -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Alex Tang <altitude@umich.edu> or Alex Tang <altitude@cic.net> iQCVAwUBMHLsMaNd+TOtm9v5AQGbGQQAiFMaOyaLQlJgO+47dkw4H4O4FP8dJooR lkFmooBTFr/BWaZ7Zl9KFwCSwm/COH5ZfQpf6zo0pWlvGYDVAYPomaV90Z1zg+dk 0jNhidLwCrxlNOKa+MyqBJiUpfyq76OW46A9V1VDa5OH8g8bbv8zn//GJCGlF+6K 3s+zjFkR4tM= =0I/O -----END PGP SIGNATURE-----
Jeff Weinstein wrote:
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() [lots deleted]
I agree with a lot of what you say Jeff. What I would do is set the string limits to be whatever the specs allow. For instance, in the case of domain names, the limit is supposed to be 256. In a mailto: just what is the limit of an RFC822 valid e-mail address? I will say that Netscape is a very robust program. I have created documents with 10,000 nested <UL> lists, and the program didn't dump. I have created forms with 10,000 selection widgets with overlong labels and variable names and it handled them (didn't diusplay them very well) However, I am a little weary of netscape allowing lists and forms having 10,000 levels. For one thing, although the 10,000 nested lists didn't crash netscape, they did use up all the swap space on my computer except for 300k. A 10K byte document was able to exhaust 32megs of ram. When I combined supernested lists, with overlong FORM variable names, and an extra long title, I did get a few sporadic coredumps. Some people may have a religious position on browsers limiting SGML/HTML nested structures (because they feel the browser should be able to handle any "legal" document), but I for one am more pragmatic. I hope you don't take my criticisms as an attack on your programmers. Netscape is my all around favorite application. I just want to see it improved and safer. -Ray
Ray Cromwell wrote:
I agree with a lot of what you say Jeff. What I would do is set the string limits to be whatever the specs allow. For instance, in the case of domain names, the limit is supposed to be 256. In a mailto: just what is the limit of an RFC822 valid e-mail address?
Yes, we couldn't get to this type of stuff in the 1.12 patch. We will be doing this sort of stuff in 2.0.
I will say that Netscape is a very robust program. I have created documents with 10,000 nested <UL> lists, and the program didn't dump. I have created forms with 10,000 selection widgets with overlong labels and variable names and it handled them (didn't diusplay them very well) However, I am a little weary of netscape allowing lists and forms having 10,000 levels. For one thing, although the 10,000 nested lists didn't crash netscape, they did use up all the swap space on my computer except for 300k. A 10K byte document was able to exhaust 32megs of ram.
On unix you can use the csh(1) limit builtin to limit the size of your netscape process. As I understand it, the Mac also has such a thing. I'm not sure about windows. Maybe we should put a preference in Netscape for how much heap memory to use... --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
participants (6)
-
Alex Tang -
Jeff Weinstein -
jsw＠neon.netscape.com -
Ray Cromwell -
sameer -
tomw＠orac.engr.sgi.com