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