This was written without any special insider knowledge. I’ve simply watched, paid attention, and kept track for the last two years. Often when I report a plugin, Mark and Otto are nice enough to explain things to me, and I’ve listened.
Occasionally a plugin vanishes from the WordPress repository. As a forum mod I tend to see people freak about this more often than not, and the question that inevitably comes up is ‘Why doesn’t WordPress publicize these things?’
Let’s go down the list for why a plugin is removed first. This list is very short, and boils down to three:
- It breaks the rules
- It has a security exploit
- The author asks for it to be removed
That’s pretty much it. The rules cover a lot, though Otto and I have been known to sum it up with ‘Don’t be a spamming dick.’ I actually had the chance to talk to folks about this before the ‘expanded guidelines’ went live, and I think I have a pretty good understanding of what the rules are. The majority of plugins, that I see removed, are done so for the most obvious reasons:
- Phoning home (i.e. sending the author data about you without your permission)
- Forward facing links (i.e. opt OUT links on the front of your site when you use the plugin)
- Affiliate links (i.e. the author gets revenue from the plugin without disclosure)
- Obfuscated code
None of those are security reasons, and most of them are ‘fixed’ by us reporting the plugin, the plugin repo mods contacting the author, the author making the fix, and all is well. When the author doesn’t reply, or in the case of a ‘phone home’, often the plugin is yanked from the repo pending review. So where are these ‘security reasons’ to yank a plugin, and why should WordPress disclose them. Phoning home is, sometimes, a security reason, depending on what’s actually being transmitted.Usually it’s a vulnerability or an outright backdoor that would be a reason to pull a plugin.
There’s an argument that ‘Trust requires transparency’ when it comes to security (see Verisign’s recent rigmarole) and that would mean WordPress needs to publish things like ‘This month, these plugins were removed for this reason.’ Except WordPress doesn’t, and in fact, if you look, rarely do companies do this until they have a fix. The ‘problem’ with WordPress is they don’t do the fix, the plugin devs do, and a surprisingly high amount of times, the plugin author fucks off like a monkey.
On the other side of this argument is FUD(Fear, Uncertainty and Doubt) which is something you never want to feed. Look at the plugin “ToolsPack,” helpfully shown up on Sucuri. Now that was never hosted on WordPress.org, but if it had been, it would have been removed for exploitation. But once the offending plugin is removed, should WP go ahead
In October of 2010, WordPress.org ‘introduced’ a kill switch for plugins. Not really, but kind of. BlogPress SEO was spam. Yoast, one of the few true ‘SEO experts’ I know of, caught it and decided to fix it the best way he knew how. See, this plugin was never on the WordPress repository and so WP could do little about it. Yoast registered a plugin with the same name, gave it a newer version of the plugin, and everyone saw that as an ‘update’ and thus were saved. Sort of. Now, even Yoast admits this is abuse of the system, and I’ll leave the coulda/woulda/shoulda to someone else.
The reason I bring it up is this shows there is a way to handle bad plugins. But it’s not very efficient, it’s not very friendly, and it doesn’t promise that it will work. First off, not enough people run updates, and secondly it’s putting a lot of work on a very small group of people. While the theme reviewers have a lot of folks helping out, the plugins do not. Should they? Yes, but the number of people who understand all the code that could be in a plugin is far smaller than for a theme. I suppose it’s saying ‘plugins are harder than themes.’ I may be wrong, but it’s how I feel.
To fix all this, you’d need to basically reboot the plugins directory, turn them all off, review each of the 18,000+ plugins, and turn them back on. Then you need an Otto or Nacin going through each one to make sure every check in is okay, every update and every change isn’t spamming. Oh yes, that’s what happens to theme devs, didn’t you know? All releases are approved before they go live. Can you see the plugin developers agreeing to that? That’s a nonsense complaint of mine, actually. If tomorrow the rules changed, maybe half the plugins in the repo would vanish and never come back, but most of the rest would be fine. Of course, we would need a dedicated team of people to do nothing but review and approve plugins to keep up with the traffic.
So accepting what we have today, the wild west, why isn’t there a running list of all plugins yanked from the repo, and why? The list itself isn’t a bad idea. Having a list to say ‘This plugin was disabled on this date’ would be nice for a lot of us, and more so, having the plugin page show ‘This was disabled.’ would be nice. I can even think of a couple code ways to do it, but all of them need a full time person to go through the ‘removals’ and put up a splash page with ‘If you used this plugin, please consider alternatives: .’ and ‘If you wrote this plugin, please contact plugin support.’ Also, this would increase emails to the plugins support account, not from the authors, but from people who want to know why a plugin was removed. And what about a day when a plugin is removed because of a bad thing, but the authors fix it? Did we create a false feeling of doubt in a plugin that had a typo?
On paper, it all sounds like we should be keeping a public list for this still, though. Put it all up there for the public, disclose everything.
Every time I write that sentence, I wince.
It sounds nice on paper, and all I can think is about the people who will cry foul, complain, and want to know more. “Why was this plugin removed and not that one?” Well, most of the time it’s because no one mentioned that plugin. Right now, the plugins that get yanked are ones people stumble across or report.
But why worry about a simple list of removed plugins? Because the first thing I would do, if I was a nefarious hacker, would be to script a pull from that list and scan the web looking for sites that use the plugins, thus implementing a vector for attack. See, we already know people don’t update plugins as often as they should (which is why Yoast’s ‘fix’ isn’t as good an idea as we’d hope), but now not only are we leaving people at risk, we’re opening them to even more risk. If we email them to tell them the plugin’s risky, we have the same problem.
There’s no safe way to inform people without putting anyone who’s not up to date at risk. Given that the most dangerous day to have an unpatched system is the day of disclosure, the only way WordPress, or anyone, could keep a list like that would be if, like Chrome, WP auto-pushed updates right away, forcing anyone who opened the site to upgrade. And that’s fraught with it’s own issues.
Until then, I can’t advocate anyone keeping a list of removed plugins. It’s too risky.
Comments
10 responses to “Risk vs Transparency”
Maybe there should be a separate section on the repository which could have an approval system for a small fee?
it would be more realistic than reviewing all the plugins on the repository now. anyone who wants to have their plugin in the “approved” section can request it to be reviewed.
Hate to say it, but I call malarkey on this one. Look at, e.g., the RedHat Network’s list of updated packages. All one has to do is plug the list of CVE’s and associated RPMs into a security scanning toolkit and start knocking on doors to look for exploitable systems, yet RedHat continues to publish these advisories.
The difference, though, is one of disclosure. Perhaps core should have the ability to pop up a “red alert” in the admin back end that warns people they have known-bad plugins installed and that they should either disable or update them immediately?
Yeah, and so does Microsoft, but IIRC neither publish those advisories until there’s a fix, right? Plugins aren’t ‘owned’ by WordPress, they’re owned by the dev, and many plugins are never fixed. The burden would be put on WP to fix or ‘uninstall’ the plugins if they did that, so clearly, WP can’t (easily) publish the advisory.
I think it could be a great thing, but the way it’s built out today it’s a bad idea.
The problem is that security updates are an inherently different proposition from feature updates. This much I agree with you on. However, let’s do a thought experiment.
Let’s say a security bug is found in a long-abandoned plugin. It’s pulled from the .Org repo but remains installed and active on hundreds, if not thousands of WordPress installs world-wide. Here we have a huge install base with no ability to even realize they’re running compromised code. An update will never get pushed to the repo, no update notification will ever be triggered in their Dashboards and they’ll continue running around in public with their metaphorical flies down. Either we somehow figure out how to warn these folks about this, or we watch (helplessly) as WP installs get pwned by crackers whose ingenuity and spare time know few bounds.
So in that scenario, how long do we allow people to run around with their briefs a-showin’? A week? A month? 6 months? In perpetuity?
The real answer is:
The plugin update API needs to be able to reliably classify plugins’ states:
* All clear
* Feature update (yay!)
* Security update (UPDATE NOW!)
* SECURITY FLAW IN ABANDONED PLUGIN (DISABLE YESTERDAY!!!!!11!!!eleventy)
There has to be transparency, there must be notification, otherwise people will end up pwned. And then you and your cohorts in the Forums Admin Brigade will field nasty, distraught posts asking how to retrieve backups from a cracked site.
And that’s the point, which you made very well. Until there’s a system in place, we can’t be transparent because of the risk. ONCE a system is in place (and yes, I want it as much as you), then it’s affordable to do so. But today? Won’t help as much as it should.
Personally I think a way to push emergency updates to fix ‘evil’ plugins ala Chrome is the best way to do it. No matter what, though, a plan from the repo end has to be made. How do we flag a plugin as vulnerable? How do we ensure it’s fixed? How do we alert people when it can’t be and must be removed, knowing their sites may depend on the plugin?
There are too many variables to slap a quick fix on it, but thinking about it (as you and I and others are) is the first setp.
I still can’t suggest we go transparent today, without a support plan in place.
I tend to agree with Doug, that the risk of lack of disclosure outweighs the risk of disclosure. Even in your scenario, I think you over-state the risk of disclosure. Simply publishing a list of removed Plugins, along with a reason (license, bad behavior, security, etc.) doesn’t provide an attack vector. A script kiddie can scrape that list, but can’t do anything malicious with it unless/until he discovers the security vulnerability in the Plugin code.
I would wager that those who exploit such vulnerabilities don’t need to wait for WPORG to publish such a list before finding those vulnerabilities for themselves. Exhibit A: TimThumb. And therein lies the rub: the black-hat crowd already knows about a given Plugin’s security vulnerabilities. End users currently have no way of knowing about those same vulnerabilities.
A published list would at least be a starting point to which to direct end users who want to know what Plugins might be unsafe – even if it is unable to reach less-vigilant end users. I think it is, at a minimum, the proper first step.
I’ve been out all day and haven’t had a chance to follow-up, but Chip speaks many of my thoughts aloud.
The status quo is this: black hats are probing at WordPress installs and plugins alike. They may be rebuffed by our elite coding skills, or they may find a way to exploit some un-escaped text fields and pwn WP instances at will. The point is, though, the single most valuable kind of security exploit for the exploiters is one only they know about. If we’re not even allowing people the chance to know that they’re running insecure code, we’re handing the malefactors a victory by default.
You also claim there’s no recourse. This is untrue — users can disable plugins until such time as a fix can be pushed. The equation changes significantly for the Core, and there’s obviously a security response team and process in place for it.
I just hate giving those nasty crackers additional cudgels with which to beat me about the head, shoulders and tender parts.
Can yes. Will? I think not, given the fact of how public the timthumb hack and shenanigans are, and how many people are still shocked to read that this is a vulnerability after they’ve been hacked. Basically I think that the people who read this site are the ‘smart’ people, the techs who are on the ball anyway, and I think we’re the 20%. The 80% of users are ‘set it and forget it.’ They won’t look at their dash for weeks or months, and those are the ones at the greatest risk with something like that public.
Go search the forums for how many posts have “I just went to my site for the first time in X weeks and ….”
(I think they should be hosted at WP.com or some other managed host personally, but y’know…)
Dear all,
Re: ‘fixing’ or removing ‘bad’ plugins (-maybe at least somehow warning?)
I found this list of plugins with exploitable vulnerabilities recently
http://www.exploit-db.com/search/?action=search&filter_description=wordpress%20plugin
The above discussion makes me think maybe something (a plugin) that scans the list and ‘warns’ an administrator if a plugin they have is on the list, may be useful.
Or does such a plugin already exist?
http://wordpress.org/extend/plugins/wp-security-scan/ does that I think.