WordPress XSS Exploit Solves Problems… and Creates More!

[Symantec]

WordPress XSS Exploit Solves Problems… and Creates More!
<p>A proof-of-concept code exploiting newly discovered XSS vulnerabilities for the latest version of Wordpress (2.2.1) was posted today on a security blog.<br />
<br />
The researcher unveiled seven vulnerabilities, cross-site scripting (XSS) or SQL injections, whose consequences range from benign to serious, the critical ones potentially leading to blog compromising. In his haste to show his skills, this person also released a proof-of-concept (PoC) code exploiting one of these vulnerabilities.</p>

<p>The PoC in itself, as explained, is supposedly not malicious, and is designed to raise awareness and patch vulnerable versions of the WordPress publishing platform. In a few words, here’s how it works:</p>

<ul><li>A WordPress administrator browses the “Comments manager” in the administration panel</li>
<li>She clicks a link, which redirects to the PoC author’s Web page. This page checks the referrer, to see whether it might originate from a logged-on WordPress administrator (the URL would contain “wp-admin”)</li>
<li>If it does, a JavaScript routine is loaded to notify the user that WordPress has been detected and that the blog might be potentially at risk</li>
<li>The user can choose to carry on, as the pop-up message offers to hot-patch some vulnerabilities!</li>
<li>From there, an XSS vulnerability is exploited in upload.php, located under the wp-admin folder. It is used to patch three vulnerable files: link-import.php, options.php and upload.php.</li>
<li>The author is then asked to link the author’s page in the Blogroll section, in order to encourage more users to do the same.</li></ul>

<p><br />
A patch may look something like the following:<br />
<blockquote><br />
/*<br />
Security Patch added by the xxxx <br />
by xxxx http://...<br />
*/<br />
$style = preg_replace('/[^A-Za-z]/', '', $style);<br />
/* end of patch */<br />
</blockquote></p>

<p>In this example, the patch adds a sanity check for the style variable, used in upload.php. This is the same vulnerability that is used to modify WordPress in the first place.</p>

<p>Though the author’s goal is honorable, the code used to patch the three aforementioned files seems to be buggy itself. The files modified are, in fact, fully overwritten. In doing that, the author forgot to encode the ‘+’ letter, which gets interpreted as a space by the browser. This means that all instances of the ‘+’ character in the three files are replaced by spaces. One bug is then introduced in link-import.php, where ‘$i++’ gets replaced by ‘$i ’ in a loop. I’ll let you draw the consequences... a bug affecting a regular expression filter would also affect options.php.</p>

<p>Be very careful if you consider patching your WordPress system through this ‘obscure’ channel. Holes may be patched, but bugs may be introduced as well.<br />
</p>
http://www.symantec.com/enterprise/security_response/weblog/2007/08/wordpress_xss_exploit_solves_p.html
http://www.symantec.com/enterprise/security_response/weblog/2007/08/wordpress_xss_exploit_solves_p.html
Wed, 01 Aug 2007 08:28:58 -0800