Me, myself and I

July 25th, 2007

Handling URL protocol handlers

There is a lot of talk about how an application should handle URL protocol handlers. Jesper Johanson has expressed his thoughts, as has David LeBlanc, Billy Rios, Window Snyder and pdp. Billy Rios just detailed yet another potential attack vector for protocol abuse.

I don’t think it is the responsibility of the calling application to perform input validation for the called application. However, I do think it is the responsibility of the calling application to ensure that the arguments to the called application are passed along properly, which is a subtle but important distinction.

When an application registers a URL handler there are only so many ways that it can do this. For the FirefoxURL handler Firefox specified HKLM\FirefoxURL\shell\open\command as

“path\to\firefox.exe” “%1″

Skype registers itself under the callto: protocol as

“C:\Programmer\Skype\Phone\Skype.exe” “/callto:%1″

Windows Address Book registers itself under the ldap: protocol as

“C:\Programmer\Outlook Express\wab.exe” /ldap:%1

And those are pretty much the different variations we can find for registering URL protocol handlers that are to be called from the command line. Most register with quotes directly around the %1 placeholder, some have quotes around the argument and the placeholder and others don’t even surround the placeholder with quotes.

In all these cases you can avoid the potential for mishap by either escaping quotes or whitespace. It should be possible for Internet Explorer, Firefox, Opera and Safari to embed a tiny bit of string handling logic into these very defined cases.

Coincidentally, Jesper published his post about how Mozilla does not escape these quotes either in his blog post on July 20. I had just written up this very same flaw in a vulnerability report two days before, on July 18, together with a proof-of-concept exploit that jumps from Firefox to Thunderbird. Separately from all of this the Mozilla Corporation were farsighted enough to include their “-osint” fix from Firefox in Thunderbird, which was released on July 19.

As such, I am that vulnerability report unedited in my next article :)

July 23rd, 2007

SeaMonkey suite affected by URL vulnerability

This is really just a short note to detail what others have surely discovered as well.

The Mozilla Corporation released Firefox on July 17, followed by the release of Thunderbird on July 19. Both of these releases tightened up the input validation performed on command line arguments, specifically to disallow other browsers from abusing them as attack vectors through inbound arguments.

This was achieved by specifying an additional command line argument called -osint, for “operating system internal”, which was appended to any of their registered URL protocol handlers. Previously, the FirefoxURL protocol handler looked similar to the following

C:\PROGRA~1\MOZILL~3\FIREFOX.EXE -requestPending -url “%1″

Whereas after Firefox the same protocol handler was changed to

C:\PROGRA~1\MOZILL~3\FIREFOX.EXE -requestPending -osint -url “%1″

Whenever the application sees that an -osint flag has been specified it will first determine the argument name and then use the remainder of the command line as the argument value, disrupting the potential for external applications such as Internet Explorer to abuse them as attack vectors.

SeaMonkey 1.1.3 was released on July 16 but does not include this modification. As such it is still possible to perform cross application scripting on SeaMonkey from other browsers, such as Internet Explorer, who still do not escape command line arguments to URL protocol handler applications.

Firefox could be used as an attack vector through its FirefoxURL protocol handler, but SeaMonkey has not yet included the required SeaMonkeyURL protocol which would give it Vista compatibility. It does, however, register itself as the handler for protocols such as gopher: and mailto:, the latter of which we can then use as an attack vector with the following POC exploit.

<iframe src=’mailto:m -chrome “javascript:alert(1)’>

You can also find the above demonstratory exploit at All it does is to launch SeaMonkey with the following command line arguments.

SeaMonkey.exe -compose -chrome “javascript:alert(1)

And there you have it, Mozilla might have bailed out Microsoft once with their previous security update but they have yet to release an updated version of SeaMonkey which removes this attack vector. You can still exploit Internet Explorer simply by substituting “FirefoxURL” with “mailto” in your exploit :)

July 18th, 2007

Firefox fixes Internet Explorer flaw

Mozilla has just released Firefox which purportedly fixes one of the attack vectors of the Internet Explorer input validation flaw that I previously detailed. I will go on the record as stating that this does not actually fix the flaw in Internet Explorer, but simply patches one of the myriads of attack vectors.

As can be seen from the release notes this update fixes 8 different security vulnerabilities. The security update in question is MFSA 2007-23, which has the following choice quote:

Note: Other Windows applications can be called in this way and also manipulated to execute malicious code. This fix only prevents Firefox and Thunderbird from accepting bad data. This patch does not fix the vulnerability in Internet Explorer.

That is the official stance from the Mozilla Corporation, which matches my own assessment. You might remember that there was some controversy about who was to blame. I blamed Microsoft, Secunia blamed Mozilla, Mozilla blamed Microsoft and Microsoft blamed no one in particular, simply stating that it “is not a vulnerability in a Microsoft product”.

I can definitely understand the initial reaction from Microsoft. Most of the emphasis in the public vulnerability reports were dealing with Firefox, the -chrome command line argument and how to properly escape the exploit code.

However, I can still automatically launch a wide range of external applications from Internet Explorer and provide them with arbitrary command line arguments. AcroRd32.exe (Adobe Acrobat PDF Reader), aim.exe (AOL Instant Messenger), Outlook.exe, msimn.exe (Outlook Express), netmeeting.exe, HelpCtr.exe (Windows Help Center), mirc.exe, Skype.exe, wab.exe (Windows Address Book) and wmplayer.exe (Windows Media Player) – just to name a few :)

I can categorically deny that this flaw has been fixed in Internet Explorer. Nicolas Robillard even detailed this flaw back in 2004 and it has remained unpatched since long before then.

The only thing that is changing as time goes by is the exploration of new attack vectors, which simply means investigating the various command line arguments that each of the above processes will accept to execute code. As soon a new attack vector is uncovered a new exploit can be produced to automatically execute code through Internet Explorer.

That reminds me, outlook.exe is an interesting application to pick apart… ;)

July 10th, 2007

Internet Explorer 0day Exploit

There is an input validation flaw in Internet Explorer that allows you to specify arbitrary arguments to the process responsible for handling URL protocols. This is the same type of input validation vulnerability that I discovered in the Safari 3 beta (see “Safari for Windows, 0day exploit in 2 hours“).

When Firefox is installed it registers a URL protocol handler called “FirefoxURL”. A typical shell open command for this handler is as follows:

C:\\PROGRA~1\\MOZILL~2\\FIREFOX.EXE -url “%1″ -requestPending

When Internet Explorer encounters a reference to content inside the FirefoxURL URL scheme it calls ShellExecute with the EXE image path and passes the entire request URI without any input validation. A request such as the following

FirefoxURL://foo” –argument “my value

will result in the following command line being used to launch Firefox

“C:\PROGRA~1\MOZILL~2\FIREFOX.EXE” -url “firefoxurl://foo” –argument “my value/” –requestPending

As can be evidenced it is possible to specify arbitrary arguments to the “firefox.exe” process. This is where the “-chrome” command line argument comes in handy, as it allows us to specify arbitrary Javascript code which is then executed within the privileges of trusted Chrome content.

The exploit that I developed for Safari simply opened CMD.EXE without specifying any arguments, an exercise that was left for the reader. For this exploit I have chosen to demonstrate how you can specify process arguments with the nsIProcess interface found in Mozilla.

The details can be found in the;1 component and the nsiProcess interface. nsIProcess takes 3 arguments:

  • Blocking: Whether to wait until the process terminates before returning or not
  • args: An array of arguments to pass to the process
  • count: The length of the args array

As with the previous exploit it is necessary to HTML escape any characters which cannot be used directly inside the URL or the command line, such as commas and quotes. For demonstration purposes I have chosen to escape these characters with both HTML entities and dynamic string construction.

Billy Rios already highlighted a few of the shortcomings with the FirefoxURL protocol handler in “Cross Browser Scripting Demo“. The following proof-of-concept exploit takes this reasoning to its logical conclusion, namely command execution with arbitrary arguments.

<iframe src=’firefoxurl://” -chrome “javascript:C=Components.classes;I=Components.interfaces;

Remember to remove the line breaks if you want the exploit to work, they are only there for cosmetic reasons. You can also test this exploit at

And there you have it, a cross browser command injection vulnerability for Internet Explorer. I am currently having some fun with the Windows Help Center and Office Groove 2007, both of which exhibit some clear potentials for malicious manipulation, but that will have to wait for a later article :)

June 27th, 2007

PHPMailer security updates

On June 11 I published an input validation vulnerability in PHPMailer, CVE-2007-3215. Since then, a number of applications have manually patched their PHPMailer source files and released updates.

Unfortunately, PHPMailer itself has not released an official update and is still being distributed with the vulnerable version 1.73 source files.

Judas Iscariote from the Swift Mailer project added a patch file to my original bug report (1734811), which seems to have been the most widely circulated manual patch.

I guess we can safely assume that PHPMailer is now a dormant project, which should be abandoned in favor of actively maintained projects such as Switch Mailer that from the looks of it has a more structured approach to security :)

June 21st, 2007

Who made OSI king of the world?

This is not strictly security related, but I just had to write a few words about that OSI article. Rest assured that you will get some security news very soon, I found half a dozen new vulnerabilities in Safari for both Windows and OS X :)

Over at Michael Tiemann, the president of the Open Source Initiative, has written an article about the apparent misuse of the term open source. He has declared that they (OSI) want to slam down on any vendor who claims to be open source but does not use “an OSI-approved license”. In his own words:

“Enough is enough. Open Source has grown up. Now it is time for us to stand up. I believe that when we do, the vendors who ignore our norms will suddenly recognize that they really do need to make a choice: to label their software correctly and honestly, or to license it with an OSI-approved license that matches their open source label.”

I generally applaud the Open Source Initiative for their dedication in promoting open source software, but the entire premise of this article does not ring true for me. This is my public comment to Michael Tiemann, originally posted as a comment to his article.

Read the rest of this entry »

June 14th, 2007

Safari 3.01 released

Apple has just released version 3.01 of their Safari web browser, together with some release notes on their Security-announce mailing list. As you can see from those release notes the vulnerability that I discovered is one out of three that have been fixed, and as far as I can tell right now the vulnerability has indeed been fixed.

Quotes and whitespace is now filtered on any requests to external URL protocol handler applications, but other characters are still being passed without filtering so I expect to find some variations pretty soon :)

I want to congratulate Apple for fixing a serious security vulnerability in such a short time frame. Their usual response time can be counted in weeks to months. When I emailed them about the vulnerability it took them 2 days to even respond, which only happened after I asked for a non-automated reply. When I filed a bug on the WebKit tracker, bug 1481, nothing happened for a day except that some guy from ‘’ added himself to CC.

A beta version stays at the same version number until it is complete, so I guess this is positive confirmation that Safari 3 is not intended as a beta release.

As for myself, I am currently at work and will have to wait for some hours before I can dig really deep into the updated version of Safari.

Cheers :)

June 12th, 2007

Site overload, back in business

I went to the beach today at around 16:00 (4 PM) after having moderated all of your comments on my previous post “Safari for Windows, 0day exploit in 2 hours“. When I got back just now at 21:00 (9 PM) this site was no longer serving any content and a lot of people had mailed me to complain.

I am running WordPress and it was not all too happy about the abundance of visitors that came by my site today. In the last 12 hours more than 30.000 unique visitors generated more than 180.000 hits, which is quite a jump from my normal rate of 500 unique visitors per day. I guess you people like to read about security research, especially Slashdot, TechMeme and Reddit :)

Luckily I had the support of a great technical team, namely Tyron from where my site is hosted. After a brief live chat the site was back up and running just fine. I’m amazed at the level of support I have received so far from HostGator and am only happy to recommend them through the previous link (yes, it’s an affiliate signup).

So what happens next? First of all, I have read through all of your feedback about the PoC exploit and will do some tests on OS X tomorrow that will result in a positive or negative verification about whether the vulnerability can be adjusted to work on OS X as well.

Following that, I will continue to write about my security research and publish any new findings here – so remember to subscribe to my feed :)

June 12th, 2007

Safari for Windows, 0day exploit in 2 hours

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:// would be turned into a command line resembling the following.

“C:\Program Files\My Application\myprotocol.exe” “”

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://"[SPACE]argument is turned into

“C:\Program Files\My Application\myprotocol.exe” “”%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://” < foo > bar | foobar “arg1′></iframe>

which is turned into the following command line.

“C:\Program Files\My Application\myprotocol.exe” “” < 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://” |cmd /c echo “FOO’></iframe>

..Fire up procexp, launch safari and watch the output.

“C:\PROGRA~1\MOZILL~3\FIREFOX.EXE” -url “gopher://” |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.


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://" -chrome "javascript:C=Components.classes;I=Components.interfaces;

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.

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 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 :)

Thor Larholm

The site was down for a couple of hours due to Slashdot, TechMeme and Reddit.

June 11th, 2007

PHPMailer 0day remote command execution

PHPMailer is a widely deployed utility class used in PHP application to handle emails sent through sendmail, PHP mailto() or SMTP. It is used in PHP applications such as WordPress, Mantis, WebCalendar, Group-Office and Joomla. The last official release happened on July 11, 2005.

If you have configured PHPMailer to use sendmail it has a remote command execution vulnerability due to a lack of input validation. sendmail is queried through the popen function which is called with a string constructed from non-escaped user input.

Line 393 in the SendmailSend function in class.phpmailer.php has the vulnerable code. If the Sender property is set by the initiating script it is possible to execute arbitrary commands.

if ($this->Sender != "")
    $sendmail = sprintf("%s -oi -f %s -t", $this->Sendmail, $this->Sender);
    $sendmail = sprintf("%s -oi -t", $this->Sendmail);

if(!@$mail = popen($sendmail, "w"))

The Sender property is most typically set in the host application by reading the value of the e-mail field or comment forms, which is where most attack vectors will be found.

The solution of course is to properly escape the input with the escapeshellarg() or escapeshellcmd() functions.

Alternatively, you can enable the PHP feature safe_mode, though many PHP applications such as the TinyMCE spellchecker in WordPress will break as a result of this. The safe_mode documentation comes with a warning of its own:

The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren’t very realistic, many people, especially ISP’s, use safe mode for now.

I have notified PHPMailer about this on their SourceForge bug tracker, see issue 1734811 :)