Seite 2: Fox hunting

Inhaltsverzeichnis

Fox hunting

Now Mozilla and Firefox are getting into the headlines. In July 2003, I warned in a comment on heise Security that Mozilla isn't really immune to this kind of trouble. Mozilla's object model XPCOM offers quite similar methods for accessing system functions that can be scripted as well. The only question was: can external web sites abuse that functionality? They can, as Michael Krax demonstrated with his firescrolling demo: "chrome", the browser's user interface, operates with highest privileges that allow files to be read, written, and activated. Comparable to the local system zone of IE, writing a working exploit only meant he had to find a way to plant code into this chrome.

Internal affairs

A typical exploit for the Internet Explorer yielded the following code that creates a new file and executes it:

Set WshShell = CreateObject("WScript.Shell") 
Set fso = CreateObject("Scripting.FileSystemObject") 
Set f = fso.CreateTextFile(path, True) 
... 
 f.Write(" code" 
... 
f.Close 
WshShell.run(path) 

This code was taken from a demo of the c't-Browsercheck. The major elements of the recently published Mozilla exploits are quite similar. The analogue component to a FileSystemObject is the component @mozilla.org/file/local;1, which implements the interface nsILocalFile to access local files. (This nomenclature reminds me of something -- did anybody ask for coffee? ;-) So the equivalent to the above code for Mozilla looks like this:

file=Components.classes['@mozilla.org/file/local;1'].\
      createInstance(Components.interfaces.nsILocalFile);
file.initWithPath(path);
file.createUnique(Components.interfaces.nsIFile.NORMAL_FILE_TYPE,420);
outputStream=Components.classes\
   ['@mozilla.org/network/file-output-stream;1'].\
   createInstance(Components.interfaces.nsIFileOutputStream);
outputStream.init(file,0x04|0x08|0x20,420,0);
output='...';
outputStream.write(output,output.length);
outputStream.close();
file.launch(); 

This code originates from Michael Krax' firelinking demo. It creates a new file and executes it via file.launch(). Different from ActiveX XPCOM is not restricted to the windows platform. With simple modifications, the code also works on Linux and Mac OS X systems. Those changes can be deployed by a browser switch. This is exactly what the Firelinking-Demo in the c't-Browsercheck does.

Privilege Fraud

Of course, a web site normally is not allowed to write on the hard disk of its visitors. For this kind of activity the JavaScript code has to ask the PrivilegeManager for permission. This is typically done with something like:

netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect'); 

UniversalXPConnect gives unrestricted access to the whole API. The PrivilegeManager will accept such requests only in special cases; initiated from an external web site, this call usually fails. Therefore, a working exploit has to somehow ensure that this code is executed in a context that the PrivilegeManager accepts as trustworthy.

This context is delivered by the chrome. You can imagine Mozilla as an empty canvas drawn upon by several different components. The whole User Interface -- i.e., all the menus and dialogs -- are essentially (XPCOM) components that can be scripted. Essentially everything surrounding the displayed web page is called the chrome.

The modular concept of Mozilla allows to reconfigure the browser virtually at will and provides the basis for the popular extensions. The chrome requires functions and the rights to access the local system. Every now and then, a user wants to save a web page locally. To do so, the code activated by the save dialog in the file menu needs permission to save a file to disk.

The trick of the recent Mozilla exploits is to inject code into particular elements of the user interface. As Mozilla -- like all browsers -- accepts extended URLs like javascript:alert('Hello World'); one can obviously try to inject such JavaScript-URLs in places where the chrome works with URLs. There are a lot of them, and some have already proven to be vulnerable: the dialog for installing XPI plug-ins displays a little icon that originates from a URL and in the location bar, Mozilla displays the "favicon” of a web site. You can still place bets, where the next such problem occurs.

As of 13. Juli the counter is closed. With Firefox 1.0.5 the next of those holes was disclosed. The jackpot goes to those who put it on the dialog "Set As Wallpaper".