Another Netscape Bug (and possible security hole)

I've found a Netscape bug which I suspect is a buffer overflow and
may have the potential for serious damage. If it is an overflow bug,
then it may be possible to infect every computer which accesses a web
page with Netscape. To see the bug, create an html file containing
the following:

<a href="http://foo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.fo!
 o.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo/foo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.!
 bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo

.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo/foo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.f!
 oo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo> blah </a>

On my BSDI2.0 machine running Netscape 1.1N, this causes a segmentation
fault and subsequent coredump. GDB reports nothing useable (stripped
executable)

As you can see, I just chose an extremely long domain name. I guessed
that the authors of netscape probably thought something like "well,
a buffer size of 256 characters is good enough to hold any domain"

It's definately the domain that's causing it, and not the length of
the URL or the data after the domain name.
 
I also tried to overflow some netscape servers using similar techniques
(and shell metacharacters in all sorts of URLs), to no avail. I suspect
a similar attack may work against the Netscape Server if it is proxying.


Does anyone have a disassembly of Netscape, or more specifically, 
a disassembly of the URL parse and domain lookup routines? I'd be
happy to collaborate and "Hack Netscape" ;-)


Happy Hacking,

In article <199509220612.CAA11441@clark.net>, rjc@clark.net (Ray Cromwell) writes:
> I've found a Netscape bug which I suspect is a buffer overflow and
> may have the potential for serious damage. If it is an overflow bug,
> then it may be possible to infect every computer which accesses a web
> page with Netscape. To see the bug, create an html file containing
> the following:

  Thanks for the report.  I will make sure that this is fixed.

	--Jeff

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

Ray Cromwell writes:
 > 
 > I've found a Netscape bug which I suspect is a buffer overflow and
 > may have the potential for serious damage. If it is an overflow bug,
 > then it may be possible to infect every computer which accesses a web
 > page with Netscape. To see the bug, create an html file containing
 > the following:
[...]
The sortest host length I've found to cause seg fault is 356 (yes, and
not 256, 256+100 if you prefer :))
You can have a look at http://hplyot.obspm.fr/~dl/netscapesec/ for a
'demo' (click to crash)


dl
--
Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|...  Freedom
Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept

Legion of Doom SEAL Team 6 Cocaine class struggle AK-47 jihad
fissionable

Ray;

This is evidence that, as I said, they have plenty of buffer overflow
bugs. So much for the protestations to the contrary.

My suspicion is that if you used a customized HTTPd that allowed you
to shove arbitrary data into your URL, you could get the victim's copy
of netscape to fandango on the stack and do nicely arbitrary things to
the victim -- like executing "cd ~/; rm -rf ."

A "Hack Netscape" T-Shirt for the first person (Ray, here is your
chance!) to find an exploit using this! Though your demo shouldn't do
anything bad. Does everyone think Ray should get a shirt no matter what?

Perry

Ray Cromwell writes:
> 
> I've found a Netscape bug which I suspect is a buffer overflow and
> may have the potential for serious damage. If it is an overflow bug,
> then it may be possible to infect every computer which accesses a web
> page with Netscape. To see the bug, create an html file containing
> the following:
> 
> <a href="http://foo.bar.foo[rest of giant URL elided]
> 
> On my BSDI2.0 machine running Netscape 1.1N, this causes a segmentation
> fault and subsequent coredump. GDB reports nothing useable (stripped
> executable)
> 
> As you can see, I just chose an extremely long domain name. I guessed
> that the authors of netscape probably thought something like "well,
> a buffer size of 256 characters is good enough to hold any domain"
> 
> It's definately the domain that's causing it, and not the length of
> the URL or the data after the domain name.
>  
> I also tried to overflow some netscape servers using similar techniques
> (and shell metacharacters in all sorts of URLs), to no avail. I suspect
> a similar attack may work against the Netscape Server if it is proxying.
> 
> 
> Does anyone have a disassembly of Netscape, or more specifically, 
> a disassembly of the URL parse and domain lookup routines? I'd be
> happy to collaborate and "Hack Netscape" ;-)
> 
> 
> Happy Hacking,
> -Ray
>  
> 
> 
> 
>

Ray Cromwell writes:
> I've found a Netscape bug which I suspect is a buffer overflow and
> may have the potential for serious damage. If it is an overflow bug,
> then it may be possible to infect every computer which accesses a web
> page with Netscape. To see the bug, create an html file containing
> the following:

Oh brother, this is unbelievable !

I'm using Netscape 1.1N under SunOS 4.1.2.

It turns out that the same (or a similar) flaw resides in the Open Location
input routine -- perhaps this merely coincides with the code called when a
URL is clicked. Anyway, pasting a URL with an overlong domain name a la Ray's
example causes two things:

(1) Part of the Open Location window widget, below the entry box, gets
overwritten onscreen with a portion of the entered URL.

(2) Netscape crashes with a segmentation fault (no core dump that I can see).

-Futplex <futplex@pseudonym.com>

> 
> Ray Cromwell writes:
> > I've found a Netscape bug which I suspect is a buffer overflow and
> > may have the potential for serious damage. If it is an overflow bug,
> > then it may be possible to infect every computer which accesses a web
> > page with Netscape. To see the bug, create an html file containing
> > the following:
> 
> Oh brother, this is unbelievable !
> 
> I'm using Netscape 1.1N under SunOS 4.1.2.
> 
> It turns out that the same (or a similar) flaw resides in the Open Location
> input routine -- perhaps this merely coincides with the code called when a
> URL is clicked. Anyway, pasting a URL with an overlong domain name a la Ray's
> example causes two things:
> 
> (1) Part of the Open Location window widget, below the entry box, gets
> overwritten onscreen with a portion of the entered URL.
> 
> (2) Netscape crashes with a segmentation fault (no core dump that I can see).


 The bug causes random things to happen because it trashes the stack. I
just did a test with http://aaaaaaa.(repeat pattern 42 times, followed by
5 a's), that's 341 characters in the domain. After a coredump, I inspected
the stack, and it has been trashed to hell, including the PC register
which was 0x61616161 (or 'aaaa' in ascii)

THIS IS A SERIOUS BUG!


Unlike the SSL crack (which took a supercomputer to crack), or
the RNG (which doesn't affect many people since there is not much
internet commerce actually going on), this bug has the potential
to damage millions of computers! This is almost enough to scare me
away from using netscape. You can guard yourself by always observing
the URL you are about to click on, but how many people will be
able to keep that up all the time given that Surfing almost
puts many people into a trancelike state?


[I hear Perry in the background groaning and muttering "I told you so"]
These buffer overflow bugs should be taught in every programming
101 course along with fencepost errors.

I'm not even sure if I want to write the obligatory program to exploit
the hack given that some malicious jerk would probably use it
on his home page to attack people.


-Ray

On the bright side, mailto: hyperlinks containing extra-long domain names
seem to be handled comparatively safely in both Netscape and Mosaic. 
(Perhaps they just have longer buffers ? ;)

Neither Netscape nor Mosaic crashes on a mailto:// of the same length as a
ftp:// or http:// that _would_ crash them. Netscape appears to do some sort
of truncation at some point (silently); Mosaic gives you a standard "server
is not accessible or is refusing to serve the document" warning page.

(Netscape 1.1N, Mosaic 2.4, SunOS 4.1.2)

-Futplex <futplex@pseudonym.com>

> 
> On the bright side, mailto: hyperlinks containing extra-long domain names
> seem to be handled comparatively safely in both Netscape and Mosaic. 
> (Perhaps they just have longer buffers ? ;)

  Good question. My guess is, Netscape doesn't do any processing on the
mailto: hyperlink at all, but merely passes it to a real mail delivery
agent like Sendmail (or it uses MAPI under Win'95). Which begs
the question, if Netscape is executing an external delivery agent,
there may be the possiblity of sneaking an attack in there and getting
the shell to execute something.

Hmm, let me try something.


WOW!! Unbelievable! Stop the presses! I Can't believe no one ever discovered
this before! Try a page with the following URL

 test 

Muahaha! Yet another security hole! Clicking on this mailto brings up
an xterm on my machine!  Simply change the xterm& to "rm -rf /" and
bingo!


Sheesh. I better stop before I am on Netscape's most hated list.


-Ray

Disregard that last message. Those drugs I was taking must have just kicked
in. I was running another program in the background which coincidentally
brought up an xterm at the same time I clicked on the link. Damn,
and I thought I had found another bug. Ah well. There's probably one lurking
there somewhere. It was good while it lasted. When I hit "send" and
that xterm popped up, I almost jumped out of my seat. ;-) Remember
this lesson, you should always try to repeat your bugs atleast three
times. ;-)

-Ray

Ray Cromwell writes:
> WOW!! Unbelievable! Stop the presses! I Can't believe no one ever discovered
> this before! Try a page with the following URL
> 
>  test 
> 
> Muahaha! Yet another security hole! Clicking on this mailto brings up
> an xterm on my machine!  

This is curious, because Netscape 1.1N doesn't do this on my setup, unless I
misunderstand your description somehow. The full string including the pipe
and all come up in the To: field of the standard Netscape mailer window. At
that stage I see it as much less of a potential risk. I can't test what
happens if you actually try to send mail to such a trojan horse URL, because
there's some screwy configuration here that makes Netscape complain about
not being able to connect to localhost (!?!) when I try to send mail from it.

Mosaic 2.4 gives a standard warning page in response to this.

(I'm using SunOS 4.1.2)

-Futplex <futplex@pseudonym.com>

On Sep 22,  4:50am, Futplex wrote:
> Subject: Re: YET ANOTHER BAD NETSCAPE HOLE!
> Ray Cromwell writes:
> > WOW!! Unbelievable! Stop the presses! I Can't believe no one ever
discovered
> > this before! Try a page with the following URL
> >
> >  test 
> >
> > Muahaha! Yet another security hole! Clicking on this mailto brings up
> > an xterm on my machine!
>
> This is curious, because Netscape 1.1N doesn't do this on my setup, unless I
> misunderstand your description somehow. The full string including the pipe
> and all come up in the To: field of the standard Netscape mailer window. At
> that stage I see it as much less of a potential risk. I can't test what
> happens if you actually try to send mail to such a trojan horse URL, because
> there's some screwy configuration here that makes Netscape complain about
> not being able to connect to localhost (!?!) when I try to send mail from it.
>
> Mosaic 2.4 gives a standard warning page in response to this.
>
> (I'm using SunOS 4.1.2)
>
> -Futplex <futplex@pseudonym.com>
>-- End of excerpt from Futplex

This is not curious. Ray uses a very old sendmail version. It's not a Netscape
bug, it's rather a sendmail bug.

Cheers

  Rainer

In article <199509220836.EAA14476@clark.net>, rjc@clark.net (Ray Cromwell) writes:
> Disregard that last message. Those drugs I was taking must have just kicked
> in. I was running another program in the background which coincidentally
> brought up an xterm at the same time I clicked on the link. Damn,
> and I thought I had found another bug. Ah well. There's probably one lurking
> there somewhere. It was good while it lasted. When I hit "send" and
> that xterm popped up, I almost jumped out of my seat. ;-) Remember
> this lesson, you should always try to repeat your bugs atleast three
> times. ;-)

  Thanks for quickly posting this retraction.  For the record, netscape
talks SMTP directly, and does not run an external program to send mail.

	--Jeff

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

> 
> In article <199509220836.EAA14476@clark.net>, rjc@clark.net (Ray Cromwell) writes:
> > Disregard that last message. Those drugs I was taking must have just kicked
> > in. I was running another program in the background which coincidentally
> > brought up an xterm at the same time I clicked on the link. Damn,
> > and I thought I had found another bug. Ah well. There's probably one lurking
> > there somewhere. It was good while it lasted. When I hit "send" and
> > that xterm popped up, I almost jumped out of my seat. ;-) Remember
> > this lesson, you should always try to repeat your bugs atleast three
> > times. ;-)
> 
>   Thanks for quickly posting this retraction.  For the record, netscape
> talks SMTP directly, and does not run an external program to send mail.

 No problem.  ;-) I congratulate you guys (Netscape) for reacting 
so quickly. ;-)

  BTW, I checked lynx for the big domain bug and it also crashes. It could
be a unix bug, but my own test program fails to crash looking up a
1000 character domain. Even so, Netscape should be enforcing a
sanity check on the domain.

-Ray

Its hardly suprising to me. Look at the link list on any dynamically
linked version of netscape and you'll see lots of calls that look very
suspicious.

I keep telling people this sort of thing and no one at Netscape
listens, although I believe that we may have made a couple of converts
in the firm now.

Perry

Ray Cromwell writes:
> > 
> > On the bright side, mailto: hyperlinks containing extra-long domain names
> > seem to be handled comparatively safely in both Netscape and Mosaic. 
> > (Perhaps they just have longer buffers ? ;)
> 
>   Good question. My guess is, Netscape doesn't do any processing on the
> mailto: hyperlink at all, but merely passes it to a real mail delivery
> agent like Sendmail (or it uses MAPI under Win'95). Which begs
> the question, if Netscape is executing an external delivery agent,
> there may be the possiblity of sneaking an attack in there and getting
> the shell to execute something.
> 
> Hmm, let me try something.
> 
> 
> WOW!! Unbelievable! Stop the presses! I Can't believe no one ever discovered
> this before! Try a page with the following URL
> 
>  test 
> 
> Muahaha! Yet another security hole! Clicking on this mailto brings up
> an xterm on my machine!  Simply change the xterm& to "rm -rf /" and
> bingo!
> 
> 
> Sheesh. I better stop before I am on Netscape's most hated list.
> 
> 
> -Ray
> 
>

I gather the Wall Street Journal is subscribed to 'punks -- seeing as
how I hear they were discussing the overflow bug today.

-- 
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

Ray Cromwell writes:
> THIS IS A SERIOUS BUG!
[...]
> [I hear Perry in the background groaning and muttering "I told you so"]

Of course I told you so. I knew what I was saying when I mentioned
buffer overflows being a big problem in code written by the NCSA team,
most of whom went over to Netscape When at NCSA, they showed very
little capacity to learn this lesson no matter how many cracks
occured. They always just tried to kludge around the thing instead of
fixing it. When I write security oriented code, I outright ban the use
of certain C library calls.

> These buffer overflow bugs should be taught in every programming
> 101 course along with fencepost errors.
> 
> I'm not even sure if I want to write the obligatory program to exploit
> the hack given that some malicious jerk would probably use it
> on his home page to attack people.

The problem is that if you don't produce a (benign) exploit people
aren't going to take it seriously enough.

Perry

> 
> The problem is that if you don't produce a (benign) exploit people
> aren't going to take it seriously enough.
> 

	And without an exploit you won't get a t-shirt. (In general,
an exploit is required for a t-shirt to be made & awarded. Exceptions
may be granted, however, depending upon the situation.)

-- 
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

Perry writes:
> > These buffer overflow bugs should be taught in every programming
> > 101 course along with fencepost errors.
> > 
> > I'm not even sure if I want to write the obligatory program to exploit
> > the hack given that some malicious jerk would probably use it
> > on his home page to attack people.
> 
> The problem is that if you don't produce a (benign) exploit people
> aren't going to take it seriously enough.

  Yeah, I guessed that. I'll work on it, I have a few doubts I have
to research first. For instance, how to embed code in the domain that
1) server/client processing won't "cook" and 2) contains no isolated
zero bytes which would null terminate the string.

  My current idea is to look in Netscape for an "exec" routine,
and call it passing a "/bin/csh" to it.

  Irregardless, it's a nasty bug given that you can crash anyone's
netscape. And on Mac/Win3.1, it may even require a reboot.

-Ray

Suggestion: Once you figure out how to exploit it for a
particular platform write a cgi-script which checks the USER_AGENT (or
whatever it is called) environment variable to make sure the netscape
that has reached your exploit is the same platform as the exploit was
written for.

> 
> Perry writes:
> > > These buffer overflow bugs should be taught in every programming
> > > 101 course along with fencepost errors.
> > > 
> > > I'm not even sure if I want to write the obligatory program to exploit
> > > the hack given that some malicious jerk would probably use it
> > > on his home page to attack people.
> > 
> > The problem is that if you don't produce a (benign) exploit people
> > aren't going to take it seriously enough.
> 
>   Yeah, I guessed that. I'll work on it, I have a few doubts I have
> to research first. For instance, how to embed code in the domain that
> 1) server/client processing won't "cook" and 2) contains no isolated
> zero bytes which would null terminate the string.
> 
>   My current idea is to look in Netscape for an "exec" routine,
> and call it passing a "/bin/csh" to it.
> 
>   Irregardless, it's a nasty bug given that you can crash anyone's
> netscape. And on Mac/Win3.1, it may even require a reboot.
> 
> -Ray
>  
> 
>  
> 
>   
> 
> 
> 


-- 
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

It's not an exploit script, but you can find an auto crash "animation"
for Ray's discovered bug on 
  http://hplyot.obspm.fr/~dl/netscapesec/c1.html
(or click from the updated http://hplyot.obspm.fr/~dl/netscapesec/)
Btw, from my tests, looks like the SunOs version is not crashing after
356 bytes like my first HPUX/Solaris test but needs a slightly longer
url, if folks can try out the above urls and confirm/infirm crash for
other platforms, thx !


dl
--
Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|...  Freedom
Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept

assassination North Korea terrorist SEAL Team 6 radar supercomputer
PLO

On Mon, 25 Sep 1995, Laurent Demailly wrote:

> 
> It's not an exploit script, but you can find an auto crash "animation"
> for Ray's discovered bug on 
>   http://hplyot.obspm.fr/~dl/netscapesec/c1.html
> (or click from the updated http://hplyot.obspm.fr/~dl/netscapesec/)

Crashes the 16-bit Windows version 1.1N.

DCF