COMMAND
	Netscape &  Mozilla  multiple  remote  vulns  (file  access,  buffer
	overflow ...)
SYSTEMS AFFECTED
	All tested versions of Mozilla (0.9.7+) and  Netscape (6.1+)
PROBLEM
	 1. Remote file access
	 =====================
	In   GreyMagic   software    [http://security.greymagic.com]    advisory
	[GM#001-NS] :
	XMLHTTP is a  component  that  is  primarily  used  for  retrieving  XML
	documents from a web server.
	On 15 Dec 2001 "Jelmer" published an advisory  titled  "MSIE6  can  read
	local files",  which  demonstrated  how  Microsoft's  XMLHTTP  component
	allows  reading  of  local  files  by  blindly   following   server-side
	redirections (patched by MS02-008).
	
	[1] http://www.xs4all.nl/~jkuperus/bug.htm
	[2] http://www.microsoft.com/technet/security/bulletin/MS02-008.asp
	
	 Discussion:
	 ===========
	Mozilla's version of XMLHTTP, the XMLHttpRequest object,  is  vulnerable
	to the exact same attack.
	By directing the "open" method to a web page that  will  redirect  to  a
	local/remote file it is possible to  fool  Mozilla  into  thinking  it's
	still in the allowed zone, therefore allowing us to read it.
	It is then possible to inspect the content  by  using  the  responseText
	property.
	 Exploit:
	 ========
	This example attempts to read  "c:/test.txt",  "getFile.asp"  internally
	redirects to "file://c:/test.txt":
	
	var oXML=new XMLHttpRequest();
	oXML.open("GET","getFile.asp",false);
	oXML.send(null);
	alert(oXML.responseText);
	
	A  fully  dynamic  proof-of-concept  demonstration  of  this  issue   is
	available at
	
	http://security.greymagic.com/adv/gm001-ns/.
	
	 -Thor Larholm [[email protected]] adds-
	As some of you may have noticed, the  above  proof-of-concept  does  not
	work in Mozilla 1.0 Release Candidate 1.
	Don't get your hopes high about this though,  the  issue  has  not  been
	fixed in moz1rc1 - the XMLHttpRequest was simply broken in this  version
	of the browser for unknown reasons, a fact not mentioned in the  release
	notes. When trying to use it, either  nothing  happens  or  the  browser
	crashes. The proof-of-concept works just  fine  in  Mozilla  0.9.9  (and
	NS6.1+), and would work fine in moz1rc1  if  the  XMLHttpRequest  object
	could be used at all.
	The Mozilla XML-Extras project  also  includes  a  document.load  method
	that is used to load XML documents.  The  same  issue  applies  to  this
	method, and a proof-of-concept demonstration that also works in  moz1rc1
	can be found at
	
	http://jscript.dk/2002/4/NS6Tests/documentload.html
	
	 2. Buffer overflow
	 ==================
	In Thor Larholm [[email protected]] post :
	The IRC:// protocol inhibited by Mozilla/NS6  seems  to  have  a  buffer
	overrun. A typical IRC URL could look like this:
	
	IRC://IRC.YOUR.TLD/#YOURCHANNEL
	
	The #YOURCHANNEL part is copied to a buffer that has a limit of 32K.  If
	the  input  exceeds  this  limit,  Mozilla  1.0  RC1  crashes  with  the
	following error:
	The exception unknown software exception  (0xc00000fd)  occured  in  the
	application at location 0x60e42edf
	Mozilla 0.9.9 gives a similar exception:
	The exception unknown software exception  (0xc00000fd)  occured  in  the
	application at location 0x60dd2c79.
	Other versions of Mozilla/NS6/Galeon  likely  share  the  same  flaw.  I
	haven't tested further on how practically  exploitable  this  is.  Short
	example online at
	
	http://jscript.dk/2002/4/moz1rc1tests/ircbufferoverrun.html
	
	 3. File detection vulnerability
	 ===============================
	In Thor Larholm [[email protected]] post :
	When embedding a stylesheet with the <LINK> element,  access  to  CSS
	files from other protocols is prohibited  by  the  security  manager.  A
	simple HTTP  redirect  circumvents  this  security  restriction  and  it
	becomes possible to use local or remote files  of  any  type,  with  the
	side effect that you can detect if specific local files exist.
	
	http://jscript.dk/2002/4/NS6Tests/LinkLocalFileDetect.asp
	
SOLUTION
	 Update (6 May 2002)
	 ======
	Latest build as of today, patches the vulnerabilities. However,  it  has
	been reported that the "Remote file access" bug may have  deeper  roots.
	Maybe you should wait a little more for a better patch.