NODE 2b66b2d4Re: New Netscape bug (in version 1.12)
tomw@orac.engr.sgi.com (Tom Weinstein)Tue, 3 Oct 95 07:38:58 PDT
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
NODE bbd20557Re: New Netscape bug (in version 1.12)
Ray Cromwell <rjc@clark.net>Tue, 3 Oct 95 23:13:45 PDT
> 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
NODE 7fb2a1a6Re: New Netscape bug (in version 1.12)
jsw@neon.netscape.com (Jeff Weinstein)Wed, 4 Oct 95 00:27:41 PDT
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.
NODE 8f6e08f1Re: New Netscape bug (in version 1.12)
sameer <sameer@c2.org>Wed, 4 Oct 95 11:05:49 PDT
> 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
NODE e59a2919Re: New Netscape bug (in version 1.12)
Alex Tang <altitude@cic.net>Wed, 4 Oct 95 13:20:55 PDT
-----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-----
NODE e7ade83bRe: New Netscape bug (in version 1.12)
Ray Cromwell <rjc@clark.net>Wed, 4 Oct 95 17:40:11 PDT
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
NODE c7f614b0Re: New Netscape bug (in version 1.12)
Jeff Weinstein <jsw@netscape.com>Wed, 4 Oct 95 20:20:41 PDT
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.
NODE dcae6188Re: New Netscape bug (in version 1.12)
tomw@orac.engr.sgi.com (Tom Weinstein)Wed, 4 Oct 95 08:18:52 PDT
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