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.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,
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
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
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
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
participants (9)
-
David Lesher -
Duncan Frissell -
futplex＠pseudonym.com -
heesen＠zpr.uni-koeln.de -
jsw＠neon.netscape.com -
Laurent Demailly -
Perry E. Metzger -
Ray Cromwell -
sameer