Plugin Security: Responsible Disclosure vs Full Disclosure

Full disclosure may not always be the best policy

Plugin security is a hot topic right now in the WordPress community, with a multitude of sites like WP Tavern, Medium, Tech Radar, and Iron Geek all throwing in their two cents. People can generally be divided into two camps: those who support Zero-Day Full Disclosure, and those who oppose it, instead opting for Responsible Disclosure. But while full disclosure can be touted as a virtue in other areas of life, this likely isn’t the best-case scenario when it comes to plugin security.

The Glaring Issues with Full Disclosure

Zero-day full disclosure involves publicly posting security issues for plugins the day they are discovered. Once the article or blog post is published with a proof of concept, the author then goes to notify the actual developer of the plugin, usually through the WordPress support forums. The issues with this method are numerous:

1. The “proof of concept” is more often than not fully functioning malicious code that can be (and, on numerous occasions, has been) used to attack the plugin’s website and users. The full disclosure post is actively aiding bad actors to attack numerous people, often by redirecting them to scams or straight-up malicious websites that can inject malware remotely.
2. WordPress has a policy that prevents these types of full disclosure posts on the plugin support forums. Therefore, the actual developer oftentimes doesn’t have a chance to see or react to these posts before forum moderators remove them.
3. Full disclosure posts are commonly used as an unethical marketing tool to encourage plugin developers to use the author’s services, either secure website development or security research and repair.

This is to say nothing of the fact that some of the big names in the Full Disclosure camp are openly blackmailing the WordPress.org team, refusing to cease their backward behavior until WordPress “cleans up their act.” According to Medium, over 160,000 websites have been put at risk over the course of this protest. Many agree that the Full Disclosure advocates are not truly concerned with security at all, but only with guilting WordPress into bending to their demands.

The Flawed Expectations of Full Disclosure

In the Full Disclosure advocate’s ideal world, WordPress and/or the third-party plugin developers would see their post the day it was published, react instantly, and be able to avoid any malicious attacks at all. However, this ideal ignores the true facts of many people’s situations:

1. There are over 55,000 plugins in the WordPress repository, and WordPress is an open-source project that is largely supported by volunteers. Combine these two facts, and you have a system that must move slower than zero-day disclosure and fixes by necessity. The teams are overworked and understaffed, so expecting them to instantly react to every single security vulnerability is wildly unrealistic.
2. Development and security fixes take time. To begin, it’s not often that a security issue is left open intentionally. There’s no reason for an honest developer who’s looking to make a living to do so, there’s no benefit to their customers or to their business. So when an issue is discovered, several things have to happen. The scope of the gap has to be defined, the code has to be written or rewritten to repair the vulnerability, and then the code has to tested before implementation to make sure it doesn’t break any other functionality. To expect this all to happen in a single day is, again, wildly unrealistic.
3. Even in the worst-case scenario where the developer is willfully refusing to implement a security fix, there’s no benefit to providing hackers with a glowing sign that shows them how to take advantage of faulty code. The plugin developer isn’t the only one being punished, all of the end users who are just trying to use the product suffer unnecessarily. It’s just unethical.

The Preferred Alternative: Responsible Disclosure

The contrasting, and overall preferred, method to Full Disclosure is called Responsible Disclosure. This involves reaching out to WordPress or the third-party plugin developer privately, through means like a separate email or phone call. This not only prevents hackers from having public access to discovered security issues, but allows more realistic expectations to be set for the plugin developers. Instead of rushing to address a zero-day security breach, the developers have time to determine the scope of the issue and come out with a researched, quality fix.

This method even benefits those who might lean towards Full Disclosure, and also have a security or development service they want to promote. With full disclosure, they publicly bash a plugin, point hackers in the right direction, and then come asking for a sale for their services. But with responsible disclosure, these same people will come off as much more trustworthy and ethical. They can be the knight in shining armor instead of the sleazy villain.

Finally, WordPress itself, the medium that supports all of these plugins in the first place, is in favor of responsible disclosure. There’s many merits to be had in following the rules and procedures of the creator of the entire platform that you’re operating on.

The Benefits of Responsible Disclosure

1. Since the authors of the plugin are contacted first and in private, they have time to create a proper fix for the security breach without increasing the risk of malicious attacks on their users.
2. Hackers and bad actors don’t receive any help or hints to be able to infiltrate breaches in website or plugin security.
3. No mistrust is inspired by unethical behavior in the WordPress community.

In short, Responsible Disclosure provides a much more safe, reliable, and realistic method of dealing with plugin security. While immediate responses from WordPress staff and plugin developers may be the ideal, it’s only possible in a perfect world. The WordPress community has made a reputation for being open and supportive, there’s no reason to sacrifice that reputation by indulging in zero-day full disclosure.

The Disclosure Sub-Camps: Amount of Disclosure

Of course, life rarely separates into clearly black and white dualities. There is a whole range of potential opportunities and levels for disclosure. To start, there are different levels for the amount of information disclosed. Full Disclosure is an obvious one, with absolutely everything disclosed. But what if only some of the details were disclosed? Would this make it more ethical to publicly post if it was only a vague idea posted regarding the nature of the security breach, as long as no actual details or proof of concept was provided? Bad actors would still know where to look, but they wouldn’t be able to copy and paste any malicious code. Is there a defined tipping point between partial disclosure and full disclosure?

Or would it be more ethical to not disclose anything? Keep the information a secret so that nobody has any chance to act on the information. After all, emails can be monitored too, right? Is there any truly safe way to provide the information?

The Disclosure Sub-Camps: Who to Disclose to

As with the amount of disclosure, the full disclosure stance on who to disclose the information to is fairly obvious, since they post the information publicly. But there are numerous different parties that could arguably receive the information. Should the information be disclosed to bigger software companies and system designers, so they know to avoid the breach in their own code? Should other security researchers be alerted, so they can be on the lookout when investigating other plugins and websites? Should the actual users of the plugin be alerted? This would prevent them from taking part in a security risk unknowingly, and potentially allow them to put pressure on the developers to fix the issue. But what if a hacker or bad actor is hiding among the end users?

The Disclosure Sub-Camps: When to Disclose

Zero-day Full Disclosure advocates disclose the information immediately, as soon as they can document the issue. But what level of disclosure should be observed after the vulnerability has been fixed? What if the developers acknowledge the issue but outright refuse to fix it? Who should be notified then? And what amount of disclosure should they receive?

The Disclosure Sub-Camps: Conclusion

Even with all of these potential combinations of disclosure, one must be sure to use full disclosure sparingly, if at all. The necessary levels of disclosure options naturally vary based on the context, and it can be a tricky situation to navigate. There are numerous end goals: being ethical, maintaining trust, public safety, and more. But it’s safe to say that public, zero-day full disclosure is unethical, ineffective, and unnecessary. There’s no single right answer to the amount of disclosure, who to disclose to, and when to disclose. But zero-day full disclosure is certainly the wrong answer, no matter which way you cut it.

Tags: plugin, security, WordPress