Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched
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
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
Mostly likely – assuming you don’t have automatic updates turned off.
Report
Thank you for reporting this.
It seems over the past few weeks there has been a steady stream of security announcements.
Report
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
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
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
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
@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
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
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
Sounds like you probably should switch Multisite / Multiuser on, then you’d only have a single WP installation to deal with.
Report
They are all client sites. With existing hosting plans with many different web hosts. So no chance of using multisite unfortunately.
Report
I feel your pain. Check out https://managewp.com. I’m a customer — not affiliated with them.
Report
Thanks Canton, I’ll look into them as well.
Report
@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
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
Processwire is a dream come true!
Enough said :)
Report
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
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
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
You could try checking comment size: https://gist.github.com/mustafauysal/28e5adca4b5c25aa84cb (untested)
Report
I have tested that code and am running it live on all of my sites. It seems to be working fine.
Report
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
That doesn’t sound right. The WordPress core team have always been EXTREMELY efficient at responding to security concerns.
Report
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
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
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
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
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
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
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
Don’t mind me. Just talking to myself.
@Sarah posted this above which does what I suggested:
Report
… probably bc. it was already widely publicize, so its maybe better, if user (who care) know how to protect their site temporary.
Report
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
That was my understanding from reading this post.
I just added this to all my sites as an mu-plugin instead:
Report
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
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
What about disqus? I hope disqus won’t affect this. I’m I right?
Report
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
How about if you use Disqus AND Akismet?
Report
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
Just updated my WSF plugin on all sites – many thanks for the update @Paul
Report
My sites are just starting to auto update to WordPress 4.2.1.
Report
Same here, my sites are all auto-updating right now.
Report
Yes WordPress released the patch for this security issue !!
Report
Yep, my sites just received the update.
Report
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
I’m getting the same error! Were you able to get a solution for this?
Report
Found this thread guys:
Report
Did you backup the database prior to the upgrade?
Report
Comments are closed.