WordPress 3.3.2 Addresses Setup XSS Vulnerabilities
Back in January we released a security advisory for WordPress, which included four vulnerabilities in the installation scripts. After discussing these issues with the WordPress team, it was decided that the vulnerabilities were not going to be fixed immediately in WordPress core considering the severity and the short window of exploitability of these issues.
Last Friday, the WordPress team released version 3.3.2, which includes a number of security improvements. Some of these improvements addressed the cross-site scripting vulnerabilities identified in our January advisory. In reviewing the changes that contributed to this fix, we noticed that WordPress addressed the issue from more than one perspective and we will cover some of them in this post.
Having access to source code can make evaluating security patches for any product a lot easier. For an open source project like WordPress, which hosts a public subversion repository, it is especially easy to get access to multiple versions. WordPress is currently hosting every version from version 1.5 to current so you can easily step into the way-back machine and see what changed between versions. All of these versions can be found here.
If you want to look at all the changes between version 3.3.1 and 3.3.2 you could just diff both releases in their entirety by checking them out and using 'diff -r 3.3.1/ 3.3.2/'. However, unless you are interested in reading through the 11,000+ changes between these versions, you need to reduce scope. Since the previously reported issue was with the /wp-admin/setup-config.php file, starting there is a good idea.
What you are seeing in the above diff are three basic additions that make the WordPress installation script more resilient against JavaScript or HTML injection:
- wp_unregister_GLOBALS – This is a basic defensive function to prevent variable overrides with implementations that enable register globals in their PHP configuration. It simply unsets (aka: destroys) the locally scoped instances of non-white listed global variables so that user-supplied input cannot override them.
- wp_magic_quotes – This function is another defensive function used to clean up variable inputs. It escapes input data to make it safer for the application to process and can help prevent JavaScript and HTML injection vulnerabilities.
- formatting.php – This is an include for the main formatting API that WordPress uses for a lot of its text wrangling. Oddly enough, in this particular case, it does not appear to be used.
Checking a handful of commit messages around the same time frame revealed that the next commit also contained changes that help with these issues. These changes sanitize the output of database error messages that are presented when the XSS vulnerability is demonstrated.
The built-in "htmlspecialchars" function is used above, which prevents the dbuser and dbhost variables from containing valid JavaScript/HTML markup that would be interpreted when they are displayed/output to the end user. Therefore, if someone managed to bypass the additional input controls added in the first set of changes, they would also have to deal with additional sanitation of their output. This makes it much more difficult for an attacker to use this attack vector.
For those of you running WordPress as a blogging and/or CMS system, a number of other important security updates where included in last Friday's release. If you are not running the current stable version already, upgrading to the latest version is highly recommended.
PS - Kudos to the WordPress team on their recent 3.3.2 release and by addressing this issue and many others at multiple levels in the WordPress core.