Cancel

Jeff Chandler

XSS Vulnerability in Jetpack and the Twenty Fifteen Default Theme Affects Millions of WordPress Users

Jetpack and the Twenty Fifteen default theme have been updated after a DOM-based Cross-Site Scripting (XSS) vulnerability was discovered. According to Sucuri, any plugin or theme that uses Genericons is vulnerable due to an insecure file included within the package.

Genericons ships with a file called example.html which is vulnerable to attack from the Document Object Model level or DOM for short. The Open Web Application Security Project defines a DOM based attack as:

DOM Based XSS (or as it is called in some texts, ‘type-0 XSS’) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM ‘environment’ in the victim’s browser used by the original client side script, so that the client side code runs in an ‘unexpected’ manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

The payload for these types of attacks is executed directly in the browser. Even Sucuri’s website firewall is unable to block the attack since it never gets the chance to see it. The company however, has virtually patched the vulnerability.

Sucuri worked with a number of hosting providers to identify and remove the example.html file from their servers. If you use the following webhosts, you should already be patched as of a week ago.

  • GoDaddy
  • HostPapa
  • DreamHost
  • ClickHost
  • InMotion
  • WPEngine
  • Pagely
  • Pressable
  • Websynthesis
  • Site5
  • SiteGround

According to Sucuri, the example.html file was used for debugging and testing purposes but was mistakenly left inside the directory after the project was packaged for production environments. This simple oversight has placed millions of sites at risk as Twenty Fifteen is a default theme that ships with WordPress.

You should update the Twenty Fifteen theme and Jetpack regardless of which webhost you’re using. You should also remain vigilant and keep an eye out for additional plugin and theme updates. If possible, manually remove example.html from within the Genericons directory.

Update

WordPress 4.2.2 is available as a security update that addresses the Genericons issue and contains bug fixes.

Category:
Tags: , , ,
52

52 responses to “XSS Vulnerability in Jetpack and the Twenty Fifteen Default Theme Affects Millions of WordPress Users”

    • That’s the point. Nothing is safe. Which is why software updates and keeping a WordPress site up to date is such a critical piece of running a WordPress site.

      This applies to everything from WordPress itself, WordPress plugins, WordPress themes, the browser you are using, the operating system you are using on the device you are using. There is no such thing as bug free software and security vulnerabilities are a fact of life.

      But it shouldn’t scare anyone from not using software. Or WordPress. Or Jetpack. Or Twenty Fifteen. Just keep your software updated in a timely manner and you will likely never have a vulnerability exploited in between updates.

      Don’t keep things updated at all, or wait weeks to click update on plugins and themes… and all bets are off. It’s the big reason i’ve been a major proponent of expanding in some form the background automatic updates to plugins and themes and not just core as the suggested best practice.

      Create forum topic from comment

    • This is a vulnerability that to me, has come out of left field. Never would have thought such a small mishap like this could affect so many sites. I am very sympathetic to who ever it is that forgot to remove example.html from the Genericons directory before shipping it.

      Create forum topic from comment

        • Yes, the file was their intentionally, and its usage as such in core established doing so as a “best practice”.

          The entire genericons package has been included with all of the bundled themes since Twenty Thirteen, since WordPress 3.8. Specifically, this practice was introduced in this ticket: https://core.trac.wordpress.org/ticket/25085#comment:16. The goal was to make it easier to update the genericons package when updates were released, as well as to make its handling more consistent across the different themes. However, since the vulnerability was introduced in a newer version of genericons that is in Twenty Fifteen but hasn’t yet been bundled with Twenty Thirteen or Fourteen, the root cause of the example.html file’s presence was somewhat less clear.

          Bottom line, the issue was with Genericons itself, and everyone did a great job of addressing the issue in all of the widely distributed places that it’s bundled despite the timeline issues.

          Create forum topic from comment

  6. Jeff, this is actually quite concerning. WP’s plugins and themes has always be plagued with security issues, both small and big, but I think something went wrong with the timeline on this one.

    Although many webhosts had this patched a week back, it clearly wasn’t the case with anyone not using them. I’m not sure what the right answer is when it comes to fixing security vulnerabilities, but I would think the updates should be out at least a day before this issue becomes public in cases where people knew about it.

    Looking at JetPack’s changelog, there were two updates yesterday without the fix and one today with the fix. If Sucuri knew about this a week ago, then am not sure why it wasn’t fixed in 3.5.1 or 3.5.2.

    Create forum topic from comment

  7. I’ve of course updated everything, including client sites, but what bothers me about this is (a) the fact that this wasn’t updated even though it was known about a week ago, and (b) all the tech sites wil of course flog the vuln, but no one will flog the fact that it has been patched. This isn’t technically a WordPress flaw, but a Genericons flaw, so strictly speaking anything using it should be either checking for the bad file in their packages or individually removing it on a case-by-case basis. Yet WordPress will once again take the hit.

    Create forum topic from comment

  13. Another day, another security problem with wordpress, and one that brings out a serious problem on the install and patch level:

    WORDPRESS DOESN”T DELETE OLD CODE, it just overwrites.

    What it means is that this “update” by itself doesn’t actually fix the problem unless you first delete the offending files. The example file occurs in a number of themes, and without manually removing the file, the security issue will not be easily fixed.

    My recommendation for wordpress is to stop working on 4.3, and start working on a version 5.0 – with the requirement of a full and complete deletion of code before the install. It’s time to clean up all of the old legacy code and stuff that ends up cluttering older installs.

    Oh, and getting to the third major update in a week is having a pretty serious impact on my productivity. The only part of wordpress scaling right now is workload to maintain the product.

    Create forum topic from comment

    • Security plugins are totally useless…

      Well, security plugins aren’t comic book super heroes. They aren’t warp drives, transporter or cloaking devices.

      They’re more comparable to safeties on firearms. Hard to say which would be more alarming, the guy who thinks a safety eliminates all the risk (and responsibility), or the guy who won’t use one because it doesn’t.

      Security plugins are extremely diverse tools, and most interesting to casually study & compare.

      My mother wouldn’t buy me a Superman cape when I was 4.

      Create forum topic from comment

  16. I should also point out that any extra files or no longer in use files will not get deleted even by an update unless you first remove code. So as an example, Yoast recent “vendor” directory problem means I am having a fun time manually deleting his plug in from 200 sites and re-uploading it, because just uploading the new version would leave a bunch of files around. If any of them have any security issues (as examples seems to have from time to time) then there is potential that this is a problem down the road. How many other plug in and theme designers have removed unsecure or unwanted files from their updates without telling people they need to delete the unused files?

    I smell a ticking time bomb. Something old will come back to bite us all in the butt one of these days.

    Create forum topic from comment

    • Updating a plugin from the WordPress.org repository from within WP-Admin should delete the folder and then create a fresh folder with the updated version. I believe the same happens for themes as well.

      For manual updates, that is the same approach that needs to be taken. Delete the folder and upload a fresh copy of the updated file. Otherwise, as you say, something old will come back to bite us.

      Create forum topic from comment

      • Otto, that is only true on automated updates. Manual updates (uploading files) does not such thing. The automated process does not apply to all installs – many are not automated because they don’t want their sites to get broken by unchecked updates.

        Create forum topic from comment

        • Let me add this: In this exceptional case code was added to the update process. Generally, this is not the case. Most theme updates are done without core updates, and theme updates generally don’t clean up.

          Create forum topic from comment

          • alex:

            First, if you follow the instructions for a manual update properly, as given here: https://codex.wordpress.org/Updating_WordPress#Manual_Update , then you might notice step 4 has the word “Delete” in it.

            Secondly, theme and plugin updates performed through the one-click process do indeed “clean up”, because they delete the entire theme or plugin directory during that process, and replace it.

            Simply overwriting files and leaving old ones around is not a proper way to do an upgrade, and it’s not the way done by WordPress itself or the way given in our instructions.

            Create forum topic from comment

  17. No, Alex – this is too easy to test, scientifically.

    Just FTP a cruft-file up to a plugin or theme that is about to be updated. Follow through with the update. Observe the cruft-file vanish.

    Just now I had 2 plugins that were ready to update. (I get the notices, but I have a plugin that lets me do it with my own fingers.) I created a text file called “test.txt”, containing only the word “test”, and saved it on my desktop.

    In FileZilla, I navigated in my remote shared hosting environment (I also keep localhost environments) to the plugin that I am about to update, and uploaded “test.txt” into it. Then I hit Update in Admin. Then I hit Refresh in FileZilla. “test.txt” vanishes, right before my eyes, and all the file-dates change to today.

    Orphan files etc do not hang around in wp-content subdirectories, when a theme or plugin is updated. Those of us who tinker around with our own files in these content-subdirs, have known all along you have to have the mod-files somewhere else, when you click the update-button – or they’re gone.

    Maybe you’re thinking ‘Linux’, Alex. Ubuntu does quite a bit of ‘leaving’ of files for apps & packages, when they are updated or removed. We have a special app for hunting these down … and in an active environment we may have a series of the same file, with different dates or identifiers … and can revert or reset to a previous state, etc. Config files (of which Linux is fond) may also retain ‘dead’ values & settings.)

    Not in anything like a modern WordPress, though (and probably not in PaleoPress, either).

    Create forum topic from comment

  18. For the past few weeks we’ve seen a ton of security updates and fixes. This should be seen as a good thing since this means security is an issue being taken seriously and addressed swiftly.

    The developer docs should get updated with notes regarding vulnerabilities and such if applicable (e.g. The recent XSS on some url functions)

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.