Dissecting the WordPress 5.2.3 Update

Last week, WordPress released version 5.2.3 which was a security and maintenance update, and as such, contained many security fixes. Part of our day to day work is to analyse these security releases, discover what security issue it is fixing and come up with a Proof of Concept for further internal testing.

Based on our analysis, none of the vulnerabilities fixed in this release are major. They all require some level of privileged-user interaction or access to high-privilege accounts. In some instances, these bugs could only be self-inflicted, in which case some serious social engineering work would be required in order to successfully exploit them.

Nevertheless, you should update your website to protect yourself against these attacks.

This post gives more details on some of the most interesting vulnerabilities WordPress 5.2.3 fixed.

Technical Analysis

Stored XSS in Post Preview

It seems that WordPress had an old legacy snippet which was originally designed to address a “JavaScript bug with foreign languages” by converting UTF-8 URL encoding to HTML entities.

It turns out it could have made it possible for attackers with some level of privilege, like contributors, to store XSS payloads in booby-trapped posts. For that attack to work, another user with higher privileges, like an administrator, would have to preview the post.

One of the possible ways to leverage this bug would be for the malicious contributor to add an anchor tag in his post pointing to:

The %u003A part would be decoded by the callback function resulting in:

This would be interpreted as JavaScript and launch an alert box once that anchor link is clicked on.

Stored XSS in Comments

The changelog description for this bug mentions the following:

 “The second was a cross-site scripting vulnerability in stored comments.”

From a technical standpoint, this line is ambiguous. It could be understood in two different ways:

1. The issue being fixed was a Stored XSS vulnerability affecting WordPress’ comment  system.
2. The vulnerability could be exploited by using comments stored on the site, implying more steps were required to conduct a successful attack.

Our preliminary analysis showed that it might be the latter and would require some very specific steps to be performed by the site’s administrator, using an attacker’s comment. If that is the only case in which this vulnerability is exploitable, we highly doubt to see attempts to exploit this vulnerability in the wild.

As shown in this changeset, it seems  wp_rel_nofollow_callback used to run the shortcode_parse_atts function to parse HTML tag attributes. While this use-case is close to what it was designed to do, shortcodes present some features that regular HTML tags don’t have: support for C-like escape sequences.

This is a big deal since the decoded values are re-appended to the final comment if the rel attribute is detected. Unfortunately for attackers, it is impossible for regular visitors to add that attribute directly in their comment since wp_kses doesn’t explicitly allow it, so multiple steps are required.

The attack flow would be something like the following:

1. The attacker posts a malicious comment, containing an anchor with the following: href=”javascript\x3aalert(1);”.
2. The wp_rel_nofollow_callback automatically adds a rel=”nofollow” attribute to the tag.
3. An administrator would need to open the comment editing view, on the administration dashboard, and re-save that comment without modifying anything. This will now force the script to decode the escape sequences in all the attributes of that tag. The href attribute will then contain javascript:alert(1); which allows Javascript code to run when that link is clicked on.

Reflected XSS in Media Uploads

This vulnerability can only occur when a user tries to upload a file with a specially crafted filename, while he doesn’t have the permission to upload a file in this context.

This can be in one of the following scenarios:

• The user can’t upload files at all.
• The user can’t upload files on the specified post.
• The user tries replacing a header or background image with an invalid file.

The response, as it contains the file name and an HTML content type, would contain the XSS.

Since this action is protected by a nonce, this can’t be used in a cross-site request forgery (CSRF) to target other users.

This vulnerability was fixed by escaping the file name with esc_html under all scenarios, as well as replacing the content type of the answer from text/html to text/plain.

You can view the complete changelog on the WordPress trac here: https://core.trac.wordpress.org/changeset/45936

URL Sanitization Issues

The esc_url function is used to sanitize URLs so they are safe to be appended in the context of an HTML tag attribute. Unfortunately, there are some ways to bypass that protection due to a bug in the wp_kses_bad_protocol_once function, which is used by esc_url to validate the protocol used in a given URL.

According to the patch, this function could have failed to detect malicious protocols when dealing with incomplete HTML entities which, even if they lack an ending semicolon, are still decoded properly by the browser.

As a result, an attacker could bypass that protection by using a URL like:

JQuery Update to Patch Prototype Pollution

WordPress patched its JQuery version with the most recent security update.

This update removes the possibility of exploiting Prototype Pollution attacks. There are no known exploits using this technique.

Conclusion

Reversing security patches is an interesting challenge. Only using the patch, you have to deduce what the underlying intent was. Sometimes it is a trivial exercise and there is a direct relation between the fix and the issue.

Other times, as this release makes it clear, you have to step back to see the bigger picture; investigate how the dots interconnects; rule out the obvious dead ends an attacker would hit and what remains, which more often than not, is the issue you were looking for.

If your WordPress installation  was not automatically updated yet, we strongly encourage WordPress users to ensure their site is up to date as soon as possible. Users who are unable to update immediately can leverage the Sucuri Firewall (or equivalent technology) to virtually patch the vulnerability.