Larholm.com

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

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