WP Tavern

Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched

Sarah Gooding · · 50 Comments

Klikki Oy is reporting a new comment XSS exploit vulnerability in WordPress 4.2, 4.1.2, 4.1.1, and 3.9.3, which allows an unauthenticated attacker to inject JavaScript into comments.

If triggered by a logged-in administrator, under default settings the attacker can leverage the vulnerability to execute arbitrary code on the server via the plugin and theme editors.

Alternatively the attacker could change the administrator’s password, create new administrator accounts, or do whatever else the currently logged-in administrator can do on the target system.

This particular vulnerability is similar to one reported by Cedric Van Bockhaven in 2014, which was patched in the most recent WordPress 4.1.2 security release. That particular vulnerability was related to four-byte characters being inserted into comments, causing premature truncation by MySQL.

In this instance, an attacker posts an excessively long comment in order to trigger the MySQL TEXT type size limit, which truncates the comment as it is inserted into the database.

The truncation results in malformed HTML generated on the page. The attacker can supply any attributes in the allowed HTML tags, in the same way as with the two recently published stored XSS vulnerabilities affecting the WordPress core.

In these two cases, the injected JavaScript apparently can’t be triggered in the administrative Dashboard so these exploits seem to require getting around comment moderation e.g. by posting one harmless comment first.

A patch from the WordPress security team should be forthcoming. At this time the team could not provide an ETA, but in the meantime there are a few things users can do to mitigate the risk.

“Your best option is to install Akismet (which has already been configured to block this attack), or disable comments,” core contributor Gary Pendergast said in response to inquiries on the WordPress #core Slack channel. “JavaScript is blocked by wp_kses(). Akismet blocks this specific attack, which gets around wp_kses()’s protection.”

WordPress users can also temporarily disable comments in the meantime until the patch has been issued by the WordPress security team.

50 Comments

  1. Keith Davis

    Sounds as though disable comments is the way to go initially and then wait for the update.

    Presumably this will be an auto update Sarah?

    Report

  2. David McCan

    Thank you for reporting this.

    It seems over the past few weeks there has been a steady stream of security announcements.

    Report

  3. Matt

    Argh, just finished updating my 60 or so sites this morning to 4.2! … very unhappy :(

    Now I can do it again, for about half of them, which can’t be autoupdated … that’s four updates this week. Slowly but surely my job changes from being a web developer to full time WordPress maintainer.

    Report

    • John Parris

      With 60 sites under your control, you’re definitely a WordPress maintainer. 60 sites of any kind is a responsibility though, not just WP. Try a service like WP Remote. It will make your life easier.

      Report

      • In reply to John Parris
        Matt

        Can look into it. Although having such a single point of failure for all/many of my sites is a drawback. Certainly because it’s free and ‘no guarantees given’.

        Report

        • In reply to Matt
          John Parris

          I hear you. A single point of failure isn’t ideal, but manually managing the number of sites you have now and will have in a year from now it’s scalable. I was also leery of the free price initially, because I don’t want to see them neglect it or shut it down due to it not being profitable or sustainable. So far so good on that front, but I’d pay them something to use it for sure. I wouldn’t mind seeing a flat rate price/year for unlimited sites. There are alternatives like ManageWP who would gladly take your money for similar services.

          Report

        • In reply to Matt
          Paul Goodchild

          @Matt, please feel free to give http://www.icontrolwp.com a try out… it’s not free, and we completely back you with top-notch support – check our WordPress.org plugin reviews and you’ll see :) Drop me line if you have any questions and I’ll help you get sorted! :)

          Report

          • In reply to Paul Goodchild
            Matt

            Thanks, I’ll take a look. This is the sort of stuff computers were invented for, so I shouldn’t be doing things manually. Although I need and want to be there when things update, because problems can always happen, mostly compatibility issues between WP, themes and plugins.

            Report

        • In reply to Matt
          alex

          Matt, I learned a long time ago not to rush to install new version of wordpress, especially not a .0 version. I always give it a couple of days because this sort of stuff often comes up. This is a very complex product, and the chance of a security issue on a significant update is reasonably high. It’s one of the many reasons I don’t allow automatic updates either.

          Report

    • xoogu

      Sounds like you probably should switch Multisite / Multiuser on, then you’d only have a single WP installation to deal with.

      Report

    • Nico

      @matt: Maybe you should try some better/more secure/easier to maintain CMS’s in the next time. Just sayin as I can really understand your annoyance. Been there, too…

      Report

      • In reply to Nico
        Matt

        Yes. Well if you know any better system please let me know. I haven’t found one so far. Even though updating WordPress does take some time (including backups, checking if everything works, etc), it’s still a lot easier and faster then for example Joomla. It’s mostly the amount of sites for me plus the hight frequency of updates. If there would be just one or two updates a year it’d already be much easier.

        Report

    • Okeowo Aderemi

      Wow seriously i don’t envy you , no developer should be using WP as a CMS there are way better and more secure platforms out there, used to maintain a WP site and it was hell, but 60 mehn that’s killer. All the best

      Report

    • tgrafx

      Yeah, I feel ya!

      I manage about 50 WordPress sites (for a total of 250 sites using WP/Joomla/Magento/etc. across 10 dedicated, self-managed servers). Keeping up with so many sites / servers (by myself) can be quite the task.

      For WordPress, I use the “Advanced Automatic Updates” plugin. This helps a lot, but software updates (in general) aren’t perfect. So I still check each website to make sure they are operating correctly after each update.

      And of course, automatic updates only go so far. There are plenty of commercial plugins and themes that require manual upgrades (i.e., Themeforest / CodeCanyon).

      My experience with MultiSite:
      A few of my clients (the ones that have a lot of domains) use Multisite. It works pretty well, but MultiSite installations themselves have their own set of issues. Generally speaking, I try to avoid having everything “under one roof”, unless the sites are 1.) for the same client, and 2.) very similar in functionality.

      I’m open to suggestions. :)

      Report

  4. stueynet

    Wondering if anyone has a clear method for securing sites from this. Aside form disable all comments via a plugin. Sites using Disqus should be safe correct? Though is there still access to post to the comments endpoint even if Disqus is enabled? Thanks in advance!

    Report

  5. Glenn Dixon

    Here’s the part that disturbs me…

    “WordPress has refused all communication attempts about security issues from us since November 2014. We have tried to reach them by email, via the national authority (CERT-FI), and via HackerOne. No answer of any kind has been received since November 20, 2014. As far as we know, they have also refused to answer the Finnish communications regulatory authority who has tried to coordinate resolving the issues we have reported, and HackerOne staff who have tried to clarify the status of them.”

    wtf?

    Report

    • Ryan Hellyer

      That doesn’t sound right. The WordPress core team have always been EXTREMELY efficient at responding to security concerns.

      Report

      • In reply to Ryan Hellyer
        Stephen Harris

        This is what the discloser is saying. Given that Klikki Oy and the WordPress’ security team have worked together before to close a vulnerabiity it does seem odd that either party would wilfully not co-operate this time round.

        A cursory glance at Klikki Oy suggests they reported this in November, and then made a minimal disclosure at the end of January.

        Report

    • Robin

      I’m very curious about this, as well. That sounds extremely unlike the WP security folks, as from what I’ve read they’re very on top of their game.

      I want to hear the WP security team’s side to this story.

      Report

  6. Wat

    Why are we writting about this if it isn’t patched yet? It’s very irresponsible to publicly announce these things until there is a fix… Now sites are that much more vulnerable because all the details are published and everyone is subjected to it.

    Report

    • Sarah Gooding

      Because it’s already been publicly announced, it’s news that has been published by multiple security outlets, and there are simple things people can do to keep their sites safe in the meantime.

      Report

    • Ryan Hellyer

      Hackers don’t read WP Tavern, they read hacker news, where this is already public knowledge. Reporting it here is to allow the rest of us to protect against it.

      Report

  7. Ryan Hellyer

    It is fairly trivial to make a plugin to hook in to the comment system and slash out all extraneous code. I’m not sure what stops wp_kses work here, but if a more aggressive system were used which just stripped out all HTML in it’s entirety, then you could presumably protect against this quite easily (at the expense of blocking all HTML).

    I don’t have time to make such thing right now. Hopefully the core team will have a fix in place before something like that is necessary.

    Report

    • Ryan Hellyer

      I should read before commenting … this is a problem with excessively long comments.

      Still, a plugin could be easily made which could trim back comments before they can hit MySQL. If anyone makes such a thing, please post back here as I’d like to install it :)

      Report

  8. Peter Cralen (@PeterCralen)

    … probably bc. it was already widely publicize, so its maybe better, if user (who care) know how to protect their site temporary.

    Report

  9. Armin

    Do I understand this correctly that as long as I don’t log in with the admin account there isn’t a problem?
    In other words, if I use a contributor account until this is fixed I should be fine?

    Report

    • Ryan Hellyer

      That was my understanding from reading this post.

      I just added this to all my sites as an mu-plugin instead:


      add_filter( 'preprocess_comment', 'nyt_preprocess_comment' );
      function nyt_preprocess_comment($comment) {
      if ( strlen( $comment['comment_content'] ) > 5000 ) {
      wp_die('Comment is too long.');
      }
      return $comment;
      }

      view raw

      gistfile1.php

      hosted with ❤ by GitHub

      Report

    • Stephen Harris

      The original report suggests that the injected JavaScript will not be triggered on the admin dashboard. If correct, you could continue to use your admin account so long as you don’t publish and view the malicious comment. I’ve personally not tested that theory however.

      Report

      • In reply to Stephen Harris
        Armin

        I only use the admin account if I need to do “admin stuff”, for day to day activities (posting entries, comment moderation) I use a contributor account. Assuming the payload isn’t triggered under a contributor account I believe I should be OK, but I will still be very careful.

        Report

  10. Akhil K A

    What about disqus? I hope disqus won’t affect this. I’m I right?

    Report

    • Ryan Hellyer

      I believe Disqus does sync up with WordPress core comments by default, so unless you have turned off that sync’ing featured, then this may still be an issue. Although it is also possible that Disqus strips super long comments anyway.

      Report

  11. Scott Paley

    How about if you use Disqus AND Akismet?

    Report

  12. Paul G.

    Just letting you know that we’ve put in a work-around to this security vulnerability into the WordPress Security Firewall ( https://wordpress.org/plugins/wp-simple-firewall/ ) – this plugin has an auto-update feature so if you’re using it, you’ll be safe enough after the upgrade :)

    Cheers!
    Paul.

    Report

  13. Peter

    Yes WordPress released the patch for this security issue !!

    Report

  14. Joe

    Yep, my sites just received the update.

    Report

  15. William Charles

    I was auto updated and now it’s asking me to update my database, when I update my data base I get the following error: Catchable fatal error: Object of class WP_Error could not be converted to string in /home/doctorof/public_html/wp-admin/includes/upgrade.php on line 1459

    Any thoughts on how to fix it? Tried the usual methods (turning off plugins, default theme etc).

    Report

  16. Rick

    Did you backup the database prior to the upgrade?

    Report

Comments are closed.

%d bloggers like this: