Cancel

Sarah Gooding

Jetpack 4.0.3 Patches a Critical XSS Vulnerability

jetpack-logo

Jetpack 4.0.3 is a security release that contains an important fix for a critical vulnerability that has been present in the plugin since version 2.0, released in 2012. According to Jetpack team member Sam Hotchkiss, a stored XSS vulnerability was found in the way that some Jetpack shortcodes are processed, which allows an attacker to insert JavaScript into comments to hijack a visitor’s browser.

This particular bug is similar to one recently found and patched in bbPress.

“Similar issues may exist in other plugins, and it’s a good reminder about the power of regular expressions to create issues when parsing data,” Hotchkiss said.

The Jetpack team has been working with the WordPress security team to push out point releases for all vulnerable branches of the plugin’s codebase, which includes all versions following 2.0. They are using WordPress’ core automatic update system, so all sites that have not explicitly opted out will receive the security update.

“Fortunately, we have no evidence of this being used in the wild,” Hotchkiss said. “However, now that this update is public, it’s just a matter of time before someone attempts to exploit it.” The Jetpack team is advising users to update as soon as possible, as the update also fixes any potential exploits that may have already been put in place.

The team credits Marc-Alexandre Montpas from Sucuri for finding the bug and disclosing it responsibly. Users will be notified about the security release via email, but those who have Akismet and/or VaultPress installed have already been protected since the first reporting of the vulnerability.

Category: ,
Tags: ,
35

35 responses to “Jetpack 4.0.3 Patches a Critical XSS Vulnerability”

    • Hi Marcus– this is a great question. Once we were notified of this vulnerability, we realized that, due to the potential severity if it were to be exploited, we owed it to our users to do everything we could to keep them safe. Thanks to help from the core security team, we were able to successfully update nearly 3 million websites in just 12 hours. Had we left this unpatched and just quietly fixed it in newer versions of Jetpack, we would leave all of our users who are running legacy versions unprotected.

      As one of the most widely used plugins in the WordPress ecosystem we have a responsibility to keep our users’ sites safe, and this proactive response was another demonstration of how seriously we take that responsibility.

      Create forum topic from comment

      • there was a security bug in a code that probably no one cared to security audit it in 4 years and yet “was another demonstration of how seriously we take that responsibility”.

        The way jetpack is built is non secure by design, too many not related features crammed together which make it hard to test and to audit. Now you forced upgrades on people that don’t use the relevant feature at all, and maybe have a good reason not to want to upgrade.

        Gone to see the plugin stats. you require wp 4.4 which means that about 45% of wordpress users just can’t upgrade to your 4.0.3. Currently only 35% use your 4.0 line so what about the rest, how and were will they get the fix for this security problem?

        Create forum topic from comment

        • We pushed 21 different fixed versions, so if you were on 4.0.x you were upgraded to 4.0.3, but if you were on 2.0.x you were upgraded to 2.0.7– we wouldn’t upgrade users to a newer major version behind the scenes. Those versions maintained the same WP version requirement as they originally had.

          Create forum topic from comment

        • @Ron. 3 million people were forced to upgrade because of a security issue which probably not applicable to most of them because they don’t use the feature.
          On that simple layer the design of the jeypack plugin badly affect it users.

          But it goes dipper, and just because you have some checkboxes to make you feel in control, doesn’t mean that the software is developed in modules which are totally separated from each other. Since they are most likely not, a change done to have feature X in module A can result in a bug in module B.

          Create forum topic from comment

        • @mark k

          Do you even know which feature was infected? Of course not.

          We found a vulnerability in the way that some Jetpack shortcodes are processed.

          Sounds like it could cover more than 1 feature to me.

          Clearly you’re a Jetpack hater. I used to be as well until I realized just how powerful it really is and how well supported it is. I don’t use every feature, but the ones I do I LOVE!

          The update was seamless (I didn’t even realize it happened and I have auto updates turned off for everything).

          It didn’t break anything and I commend the Jetpack team for getting it out there so quickly and so quietly before any waste-of-oxygen hacker dick could exploit it.

          If you have issues with Automatic so be it. Just realize any further comments you make about Jetpack and/or Automatic will be taken as they truly are – bitching of a hater that doesn’t even use it that is clearly bitter about something and wants the rest of the word to feel his pain.

          I, for one, don’t feel a thing (except I do hear a high-pitched whining sound – I’m sure it will go away soon).

          Create forum topic from comment

        • @Ron, I never hidden my dislike of the concept of jetpack. I am not hating it, (why should anyone hate a software?) I didn’t even think about commenting here if sam didn’t say that after discovering such a bug that “everything is just great”.

          Jetpack is not unique in the wordpress eco-system it is just the “king of the hill” when you measure bloat. Same thing probably can be said about “better security”, some of the complex themes and many more.

          WordPress runs on a server, it almost never being ran as a vanila install but have plugins, themes and some hacks applied to it, and as such the admin has to be able to “own” the code. The more code there is the harder it is to own it, and the “nice” thing about server code is that just because some execution paths seem to be inactive doesn’t mean they can not be triggered by a well crafted request.

          The less code you have the easier it is to identify and fix bugs, as simple as that.

          Now if you use 50% of the jetpack modules, then sure just use the whole thing, but neither of its features are “best in class”, and since they always add new ones, I assume no one uses so many feature of the plugin.

          Then there is the cost of upgrades. In properly managed sites no one just upgrades a plugin directly on production and first they test the upgrade on staging. How much time is being wasted now all over the world because of a feature that is not even relevant to the site? And in properly maintained site the push from wordpress.org just do not work as no one will let a web server to write into its plugins directory.

          And as evident by the posts on the tavern about the next bug release for jetpack, it is not like anyone can claim that it is a perfect piece of software you can just trust.

          Create forum topic from comment

        • @mark k

          In properly managed sites no one just upgrades a plugin directly on production and first they test the upgrade on staging.

          Here’s the problem with your logic. You’re thinking like a dev.

          The other 99.9% of the world (myself included) simply do a backup and roll the dice.

          I work for a medium+ sized company that spends thousands every month on the web (excluding my salary). I run 7 web properties for them (including a compete gut and redesign on one of them currently), a CRM (hosted by the vendor), social media, email marketing, PPC, etc, etc, etc. If anyone honesty believes I have the time for staging for a plugin upgrade – they’re nuts.

          Unfortunately, there are almost no real end users (I mean end users whose real business has nothing to do with WP – devs and those that make their living from WP don’t count) participating in these kind of discussions. I just choose work over sleep most times and I’ve been using WP since the very beginning (in fact I used PHP Nuke before it).

          And in properly maintained site the push from wordpress.org just do not work as no one will let a web server to write into its plugins directory.

          Again, I choose to roll the dice. I figure if it’s important enough that WP/Automatic/whoever wants to push it ASAP I need to trust them to make it happen and keep our sites secure.

          and as such the admin has to be able to “own” the code.

          I can assure you, I “own” the code. I’m the only employee that has a clue about any of this. My career hinges on there not being any catastrophic issues. I’m fine with that – I like living on the edge. :)

          Devs don’t really understand their clients’ businesses (and most don’t seem to care as long as the whiz-bang part of things work) and business owners understand the tech side even less. That needs to change.

          I don’t mean to sound like I’m complaining here. I now officially have my 100% DREAM JOB and have no intention of changing. It would just be refreshing if devs really tried to see how the other 99.9% of the WP ecosystem works. It might not be pretty but it works(ish).

          Create forum topic from comment

        • @Ron, read only the start of your comment, and it is worth to reply to by itself.

          Devs are not afraid of updates because they (think they) know where their backups are and how to recover from them. It is actually the non-techi people, for which everything is just pure magic, that are afraid to upgrade anything because it might break the magic. This is why wordpress has to support php 5.2, why 45% of wordpress sites run 4.3 or below, and why the jetpack 4.0 line is used by only 35% of jetpack users.

          Some of us are freelancers which need to justify to their clients the hours they bill. It is nice that I can do a safe upgrade procedure, but what do I say to the client? If I tell him that he needs to pay for an hour work to fix a security issue with comments, what should I tell him when he says “WTF, but the site doesn’t have any comment section at all”

          Even when you “just trust” upgrades take time and time is money if the site is not a hobby site.

          Create forum topic from comment

  5. Is it too much to ask for next time, do a FULL security audit before releasing the next version.

    Quality over Quantity.

    I know other php programs like phpbb won’t release for the sake of releasing.

    Yes I know there aren’t enough people, most people are volunteers and so forth.

    Just don’t release core/plugin/theme until you are 100% comfortable that core/plugin/theme/etc…is safe.

    If it gets delayed by a week or two, so be it. Give the c/p/t to all the devs and tell them: break it. If they are able, the fix it, repeat for the fix, and if nothing was broken then voila…you release it.

    Create forum topic from comment

    • It is not easy to audit for product that has mature and huge codebase, and of course, it’s not cheap. Even your source code has adopted in many companies that runs security audits.
      Take an example from shellshock vulnerability from most popular Bash that remains back from version 1. Many popular linux distros and even Apple OS X use Bash but this bug was found on 2014, which over 20 years from first major release.

      Create forum topic from comment

    • No security audits are perfect, and will catch absolutely everything.

      We do regularly audit the codebase for Jetpack and all our products, and even occasionally hire outside firms to conduct extensive audits — we had a full audit of the full Jetpack plugin done right around a similar security incident two years ago. It didn’t find this either.

      I’m somewhat concerned that you think the answer to security problems seems to be just “throw more audits at it” — it’s not. It’s a comprehensive approach including auditing as well as running a bug bounty program and proactively considering security implications of changes before implementing them.

      As it is, the ‘shortcode’ implementation issues were the last vestiges of some legacy code that had been used to implement shortcodes before shortcodes were even a thing in WordPress. And they interacted with some core content filters in interesting ways so that it was possible to finagle the right mix of escaping and unescaping quotation marks in content. Not easy or obvious, hence how it got missed.

      Once it was discovered, we addressed it as thoroughly and promptly and securely as we are able.

      Create forum topic from comment

  6. My installation of JetPack was basically trashed; it no longer showed up among my installed plugins. When I try to install it, the install fails. I see:

    Destination folder already exists. /home/content/76/8769676/html/wp-content/plugins/jetpack/

    Plugin install failed.

    If I manually delete the old directory (wp-content/plugins/jetpack) and its subdirectories, do I lose something significant that I haven’t already lost? Or is there some way to re-install this without deleting anything?

    Create forum topic from comment

  7. I don’t use Jetpack, and have no interest in it. But I am intrigued by the reactions to this news. On the one hand, we have some people who don’t like the plugin saying how bad it is that this could have happened. And, on the other, we have lovers of the plugin saying that this is another example of how great the plugin and its developers are.

    So when the plugin developers say that this “was another demonstration of how seriously we take that responsibility,” the lovers get even more sycophantic, while the haters laugh incredulously.

    It would be nice to think that the level of comment could get past all that. As I’ve said many times before when previous security problems have been reported (not necessarily about Jetpack), the test for whether the developers really take their responsibilities seriously is whether they have now reviewed their practices.

    It doesn’t matter how nice or well-meaning the developers are. If their practices are poor, then problems are bound to happen again, and not just because no-one can guarantee bugless code.

    So what changes in their practices have the Jetpack developers put in place?

    And, for those who think that, because I don’t use Jetpack, then this shouldn’t matter to me, you’ve completely missed the point. Jetpack has an experienced and well-resourced team of developers. If they’ve actually addressed the matter with the responsibility that they claim, then there presumably will be lessons to share with other developers, from which we’ll all benefit.

    So I ask again: what changes in their practices have the Jetpack developers put in place?

    Create forum topic from comment

    • Hi KTS915 —

      We’re continually working on reviewing and improving our processes, keep an eye out for a post going over our process (and the ways in which it has changed) in the next couple of months.

      One process improvement we’ve put into place recently is a multiple review requirement. All code must undergo review by 3 developers before its inclusion into a release. This has had a great impact on our code quality. Stay tuned for more details on our processes.

      Create forum topic from comment

      • @Sam Hotchkiss,

        All code must undergo review by 3 developers before its inclusion into a release.

        This is exactly the sort of thing I like to hear. Thanks for responding. I do hope others follow your lead.

        Create forum topic from comment

      • Good Good Good that 3 developers are included. I hope this vulnerability doesn’t occur again. With all due respect, if this was missed, what about something else that was missed. It could be possible.

        Create forum topic from comment

  8. Fact: 90% of all security vulnerabilities are insignificant and will not or cannot lead to a website getting hacked. Insignificant meaning, yes a bug exists and yes it passes exploit/pen tests to qualify it under the very misunderstood terminology/wording – Security Vulnerability.

    It sounds like this particular Jetpack bug may fall in the 10% category of significant, but then there is the other important factor to consider – the “exploited in the wild” factor. In laymans terms, is there any evidence (logs, etc) of this attack vector being used by hackers/spammers. Example: A bug exists for 3 years. After 2 years and 11 months a new attack vector starts appearing in security log files that shows a new attack vector is being used for plugin X. The attack vector is tested and is found to be a legitimate attack vector and bug that is exploitable. What this means is the Unknown Security Vulnerability has now become a Known Security Vulnerability to hackers/spammers (typically hacker/spammer groups share exploits within their own groups first, but it does not take long for other hacker/spammer groups to find and use those attack vectors).

    In any case, the bottom line and most important factor is there does not appear to be any evidence that this Jetpack bug led to any websites being hacked.

    “Fortunately, we have no evidence of this being used in the wild,” Hotchkiss said.

    There are Pen Testing tools like Kali and other tools out there, but a simpler solution that would be relatively simple to create would be a WP plugin that grabs all potential vulnerable areas of code such as form text input fields, etc., puts them into a re-usable array and then executes a battery of attack vectors with relative ease. We actually created something like that for our plugin recently (ironically all bugs over the years had already been reported to us through the years and we did not find any new ones after creating this new pen test tool), but it is raw code and not something that is ready for or planned for public use. The concept is a similar concept that is used in most pen testing tools, but focuses more on finding and checking targeted potential vulnerable code instead of running blanket/mass exploit/attack vector tests on all code and is relatively simple to create. The general idea is to first create your code scanner, which matches all code patterns that you want to check, put them into arrays and execute X. X being a remote posting form, etc.

    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.