Re: WSJ on Netscape Hole 3

Somebody wrote:
>> With Netscape 1.1 the state of the stack is much more dynamic, in
>> particular the user can be viewing documents at an arbitary depth in
>> the "web tree", each recursion will increase the stack pointer (or
>> decrease with some architectures) There is no way of knowing for
>> certain where you code will end up and thus no way to reliably alter
>> the return address on the stack to execute your arbitary code.
>

I just tested this under Solaris 2.4 and it "turns out not to be
the case." I approached my "bad" URL from a variety of other places,
passing through various other pages, and the stack structure was
still the same when I clicked on the bad guy. The big problem I'm
having on this platform is the windowing register system on the SPARC
architecture, which interacts in weird ways with the debugger.

The lack of determinacy about where the stack is loaded in global
memory _does_ seem to be a much bigger problem on the Mac, which
is still not anything approaching a multi-tasking OS. Under Unix,
proceses get their own address space to play in, which is always
the same; on Macs, with their weird relocatable heaps, you never
know where stuff is going to get loaded.

I wonder how this is handled in Windows 95....

As for objections about how worthwhile this is, it's pretty clear
that a patch will be available for this problem before we can finish
and publicize an exploit. This is not, however, the last piece of
network software that will contain problems of this sort, and it is
a good idea to build up expertise in this area. I'd also suggest going
after some of the other browsers... I know, for instance, that AOL's
browser dies horribly on these same sort of URLs.

Good luck, all.

Doug

> As for objections about how worthwhile this is, it's pretty clear
> that a patch will be available for this problem before we can finish
> and publicize an exploit.

	Which makes an exploit all the more useful. If an exploit was
published well before a patch would be available, people would make
accusations that the exploit publisher was aiding
vandalism. (Warranted or not, 8lgm gets these accusations, etc.)
Publishing the exploit after the patch is available means more of an
incentive to go get the patched version. I for one, haven't picked up
the patched netscape yet.

-- 
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 <v02120d06ac8f74e7796e@[199.2.22.120]>, cman@communities.com (Douglas Barnes) writes:
> As for objections about how worthwhile this is, it's pretty clear
> that a patch will be available for this problem before we can finish
> and publicize an exploit. This is not, however, the last piece of
> network software that will contain problems of this sort, and it is
> a good idea to build up expertise in this area. I'd also suggest going
> after some of the other browsers... I know, for instance, that AOL's
> browser dies horribly on these same sort of URLs.

  The patched version is now available at ftp://ftp.netscape.com/pub/netscape/

	--Jeff

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