Coverage of WordPress plugin vulnerabilities is rather poor and coverage of an authenticated option update vulnerability in the plugin Simple Social Buttons disclosed on Monday was no exception. For example, you had a security journalist that frequently spreads false and misleading information, Catalin Cimpanu, make this statement in regards to WordPress:
Some sites are inherently protected against this vulnerability, as their admins have already blocked user registration due to security reasons.
In reality user registration is disabled by default by WordPress, which severely limits the threat posed by authenticated vulnerabilities (since they require someone to be logged in to WordPress to exploit). You have to wonder if he made that claim up himself or someone else told him something that isn’t based in reality, but that sort of inaccurate information could be avoided by getting a second source for stories that is more knowledgeable about WordPress, but security journalist don’t seem too interested in getting things right (including simple factual items like that WordPress isn’t owned by Automattic).
It turns out there is something that seems more worthy of coverage related to this vulnerability, though something that didn’t get mentioned by in articles about it or by the discoverer, WebARX. In WebARX’s post about the vulnerability it is only explained in vague detail about how the vulnerability was run across, the post starts with this:
Finding security vulnerabilities is an important part of securing our client’s sites and improving our managed web application firewall. That is why WebARX is analyzing WordPress plugins for security issues and reporting them to competent developers or organizations.
While doing research we found a vulnerability in popular WordPress plugin Simple Social Buttons which allows non-admin users to modify WordPress installation options.
A possible explanation of how they came across this vulnerability is that they previously ran across the same type of issue with another plugin by the same developer. At the end of November they disclosed that the plugin LoginPress had a vulnerability caused by the same issue, a lack of proper security when importing plugin settings through WordPress’ AJAX functionality. That one was more limited since arbitrary options could not be updated, like the more recently disclosed vulnerability.
You would think that the developer would have made sure that their other plugins were then properly after being alerted to that issue in one of the plugins, but that wasn’t the case (we checked their other plugins and the others don’t seem to have that same functionality). That isn’t a one off issue and seems like the kind of thing that is important to understand when trying to understand why the security of WordPress plugins is so poor and what can be done to improve it.
Critical Should Mean Critical
What is also seems worth noting about this situation is the over usage of “critical” when describing vulnerabilities. For both the less serious variant of the vulnerability in LoginPress and the more serious in Simple Social Buttons the discoverer called them critical in their posts about them, “Multiple Critical Vulnerabilities in LoginPress WordPress Plugin” and “WordPress Plugin ‘Simple Social Buttons’ Critical Security Bug”. We would have a hard time even calling the vulnerability in Simple Social Buttons critical because of the more limited likelihood of exploitation due to being authenticated (though that is increased with the coverage it received). With the LoginPress vulnerabilities we haven’t seen any evidence of exploitation at attempts since they were disclosed, which seems like a good indication that calling critical is overstated.