Re: WSJ on Netscape Hole 3

[cman@communities.com (Douglas Barnes)]

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