{"id":2485,"date":"2015-06-15T16:27:51","date_gmt":"2015-06-15T22:27:51","guid":{"rendered":"http:\/\/www.whitefirdesign.com\/blog\/?p=2485"},"modified":"2015-06-15T16:27:51","modified_gmt":"2015-06-15T22:27:51","slug":"the-slow-pace-of-wordpress-plugin-vulnerabilities-getting-fixed","status":"publish","type":"post","link":"https:\/\/www.whitefirdesign.com\/blog\/2015\/06\/15\/the-slow-pace-of-wordpress-plugin-vulnerabilities-getting-fixed\/","title":{"rendered":"The Slow Pace of WordPress Plugin Vulnerabilities Getting Fixed"},"content":{"rendered":"

Since we have been reviewing publicly disclosed security vulnerabilities in WordPress plugins to add them to our Plugin Vulnerabilities plugin<\/a>, one of the things that has stood out to us is how long it can take for vulnerabilities to get fixed. Part of what makes this stand out is that in many of the cases fixing the vulnerability is quite easy, so it seems that many\u00a0developers are just not too concerned about keeping\u00a0their plugins are secure.<\/p>\n

Let’s take a look at recent example of this. Back in March\u00a0g0blin Research discovered an authenticated persistent cross-site scripting (XSS) vulnerability<\/a> in the plugin\u00a0AddThis Sharing Buttons<\/a>\u00a0(formerly\u00a0Smart Website Tools by AddThis). This plugin currently has over 200,000 active installs according to WordPress.org, has 12 listed authors, and is developed a private corporation of the same name<\/a>. The vulnerability was caused by an Ajax function that should only be accessible to Administrator level users being accessible to any registered user. That severely limits the potential danger of the vulnerability since most WordPress based websites do not allow the public to create accounts, so someone relatively trusted with malicious intent would be required for the vulnerability to be exploited. It also should make it quite easy to fix, but as the timeline included with advisory (show below) shows it took the developers over two months to fix the issue:<\/p>\n

2015-03-19: Discovered
\n2015-03-19: Vendor notified
\n2015-03-19: Vendor responded \u2013 link to report provided
\n2015-03-20: Version 4.0.7 released \u2013 issue still present
\n2015-03-26: Vendor responded with intent to fix
\n2015-03-31: Update requested from Vendor
\n2015-04-07: Vendor responded stating that a fix is in progress
\n2015-04-13: Update requested from Vendor
\n2015-04-16: Vendor states that fix is undergoing QA
\n2015-05-04: Update requested from \u00a0Vendor
\n2015-05-11: Update requested from Vendor
\n2015-05-12: Vendor states that fix was rejected by QA, has been redeveloped and has been passed back to QA for re testing.
\n2015-06-01: Notified vendor of intention to contact WordPress Plugins team
\n2015-06-03: Version 5.0.4 released \u2013 issue resolved
\n2015-06-10: Advisory released<\/p><\/blockquote>\n

So what does it take to get this type of issue fixed?<\/p>\n

There are two functions that are often used to check if someone is Administrator level user. The more widely used is to check if the user has the capability to manage_options<\/a>:<\/p>\n

current_user_can( ‘manage_options’ )<\/p>\n

That capability is normally only provided to Administrator level and above users, and allows access to WordPress settings pages. That would be particular relevant for fixing this vulnerability\u00a0as the vulnerable Ajax function is something that would have normally be accessed\u00a0from a settings page.<\/p>\n

The second function checks if a user is a Super Admin or Administrator:<\/p>\n

is_super_admin()<\/p>\n

With that function if network mode is enabled (WordPress MutliSite) it will return true\u00a0if the user is a Super Admin<\/a>\u00a0and when network is not enabled it will return true if the user is an Administrator<\/a>. Beyond the implications that this has with MultiSite websites, there is a potential that someone will accidentally use is_admin when they meant to user is_super_admin. That would be a security problem of its own, as\u00a0is_admin<\/a>\u00a0only checks if an administrative page is being requested and “does not check if the user is logged in, nor if the user even has access to the page being requested”.<\/p>\n

So what did the AddThis Developers come up after months and having a fix rejected by quality assurance?<\/p>\n

First up is the relevant function before being fixed:<\/p>\n

public function addthisAsyncLoading()
\n{
\nif ($this->_checkAsyncLoading()) {
\n$updateResult = $this->updateSettings($this->_postVariables);
\n}
\ndie; \/\/exit from the ajax request
\n}<\/p>\n

Here is the fixed version (fix bolded):<\/p>\n

public function addthisAsyncLoading()
\n{
\nif (current_user_can( ‘manage_options’ ) &&<\/strong> $this->_checkAsyncLoading()) {
\n$updateResult = $this->updateSettings($this->_postVariables);
\n}
\ndie; \/\/exit from the ajax request
\n}<\/p>\n

Why it two months to add less than a line of code is something we don’t understand. It could have been worse, in another case<\/a>\u00a0with the same failure to check on a user level, it to\u00a0 the plugin being\u00a0pulled the plugin from the Plugin Directory for the vulnerability to be fixed (following us reporting it to Plugin Directory<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"

Since we have been reviewing publicly disclosed security vulnerabilities in WordPress plugins to add them to our Plugin Vulnerabilities plugin, one of the things that has stood out to us is how long it can take for vulnerabilities to get fixed. Part of what makes this stand out is that in many of the cases … Continue reading “The Slow Pace of WordPress Plugin Vulnerabilities Getting Fixed”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25,32],"tags":[],"class_list":["post-2485","post","type-post","status-publish","format-standard","hentry","category-bad-security","category-wordpress-plugins"],"_links":{"self":[{"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/posts\/2485","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/comments?post=2485"}],"version-history":[{"count":5,"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/posts\/2485\/revisions"}],"predecessor-version":[{"id":2490,"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/posts\/2485\/revisions\/2490"}],"wp:attachment":[{"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/media?parent=2485"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/categories?post=2485"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.whitefirdesign.com\/blog\/wp-json\/wp\/v2\/tags?post=2485"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}