Disable Vulnerable Plugins

Projects Directory
11

Unfortunately not everyone who builds websites understands this responsibility or knows how to fulfill it.

I agree, passing responsibility for security to your customers isn’t right either.

The best way to prevent failure in complex systems is to address the potential failures at multiple layers. A few examples from different roles and perspectives in the context of managing a ClassicPress site:

  • Because I own ClassicPress and WordPress websites, I do what I can to stay on top of upgrades, security news etc.
  • Because I manage ClassicPress websites for other people, I do the same for their sites.
  • Because I am one of the people responsible for the ClassicPress code, I take security seriously and review new and existing code for potential issues. We also are always thinking about ways to “harden” the codebase to prevent common security issues.
  • When ClassicPress is responsible for a plugin directory, and a security problem arises with one of the plugins we list, we will need to be able to take steps to ensure our users’ continued security.

I think the best case scenario for a new vulnerability in a plugin is that we can quickly and quietly get a fix out, and for severe vulnerabilities, push the fix as an automatic update. This isn’t always going to be possible though, and sometimes it will fall to us to make hard decisions about these cases.

1 Like
15

@Marialena.S here we are debating if ClassicPress as an entity should deactivate vulnerable plugins on CP sites or just warn the user to take action.
There are legal issues with having the access level needed from ClassicPress as a CMS project to be able to deactivate a plugin on a user’s site. Also doing so can result in a broken site due to CP organization and the whole entity could be sued legally for this.
In my opinion we, as an open source project, shouldn’t be allowed to access users’ sites to perform such action of deactivation, but problem remains: is warning them enough? Many users see notices when site is already broken from the vulnerability. We need a way to indicate a plugin is unsafe obliging people to secure their sites.

2 Likes
16

This is a little bit the wrong way round.

ClassicPress could potentially face a lawsuit if it (a) intentionally or (b) negligently contributed to harming a person’s website. If we know about a vulnerability and do something to mitigate that problem, then we won’t have a problem with (a). The real issue is how to address (b).

The way to avoid liability for (b) is to act reasonably. The law is not so arrogant as to think it knows better than the professionals what reasonable behavior is; it will, by default, defer to the expertise of the professionals.

So the question turns out to be what is the most professional way to deal with such an issue, and that’s for us to work out. The likelihood is that there isn’t a one-size-fits-all answer. In some cases, notifying users of the problematic plugin will be enough. In others, deactivating it might be preferable.

Actually, this debate is really useful in legal terms (as well as in practical terms) because (a) it shows that the ClassicPress community cares about the issue (which demonstrates reasonableness) and (b) it also shows that reasonable people may disagree (which gives us wider latitude in coming to the most appropriate answer).

2 Likes
22

I never suggested that we have any sort of remote access to sites - I can’t imagine anything worse than trying to secure that; only a Politician would think it’s a good idea.

That said, it doesn’t mean the CP install itself can’t disable a plugin if it’s suitably flagged by the plugin directory, and that could be configurable.

I’m still in 2 minds about whether it’s a good idea.

5 Likes
24

This is exactly what I referred to. I’d be happy to opt-in. I think of it like this: which will cause more damage… having a broken plugin…or losing trust of my users because (et al) I wasn’t savvy enough about security. There’s no question for which scenario I’d rather be mitigating damages.

2 Likes
25

Sounds like a good thing to put on our security screen as an option that is disabled by default.

5 Likes
26

Well, we might just add a status to plugin that triggers auto-disabling of plugin when it’s flagged. Of course, this would be with some permission from security page.

2 Likes
27

How serious of a vulnerability are we talking about though?
Only those that have been publicly disclosed and are known to be exploited in the wild?

It is a different matter to have a broken site that is mainly an info site / a marketing / blog site.
It is a very different matter when that site is an e-commerce, membership or e-learning platform.
It can cause a very serious PR fall-out for the site, without any warning.

To use an analogy here: Responsible disclosure includes contacting the developer and giving them a chance to respond before taking action and publishing the information.
If you break someone’s site, that can have the same effect as public disclosure.
In terms of maintaining your customers’ respect and trust, it is much better for them to hear about security issues from you than finding out when they log in and irately start asking why the site isn’t working.
Some plugins may be easy to replace with others. It is MUCH better e-mailing a customer saying “Hey, just to let you know, we had x issue, but it has already been addressed.”
The site owner should be given at least the same consideration as is given to the developer / plugin owner.

2 Likes
28

It all gets very complex once you start adding settings for automatically disabling plugins. People will have different overall preferences, some plugins can be safely disabled on some sites but not others, some people will only want to disable some plugins for unauthenticated remote exploits, etc etc etc.

Even if we solve all that, we still have the problem of the plugin directory becoming a much more valuable target: if you can toggle the “exploit in the wild” switch you can disable plugins generally, or target one you want your plugin to replace - amongst other things.

So, the first version of the directory isn’t going to have anything like this; we’ll add it at some point, so it’s still a useful thing to define - I just want to manage expectations.

3 Likes
29

I don’t like the idea of CP disabling plugins. As each piece is supposed to be GPL compatible, and the license says

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I say let them maintain their own site, and expediting a plugin update is the best option.

4 Likes
30

Yes, but we’re talking about what happens before there’s an update available.

1 Like
31

Invisnet,

Sort of like a pre-selected fail-over?
I really like that. :thinking:

Joy,

That is about limiting legal liability, not building positive customer relationships / a brand image.
I’d say “in the hope that it will be useful” is a very important part of that sentence.
Not everyone has the same level of skill / knowledge in all areas. Personal responsibility is crucial, but so is mutual respect for each other’s competencies. People are unlikely to adopt a product they feel may leave them in the lurch to sort out a mess they don’t understand, even if it is their own mess.
Respecting someone’s autonomy does not preclude providing them with the best options reasonably possible.

32

Something else just came to mind and thought I should jot it down before I forget.

A number of plugins use custom deactivation hooks.
How would a function to automatically disable a plugin treat custom tables and so forth created by the plugin (that are deleted in by the plugin’s deactivation hook)?
Because if it just triggers the de-activation hook, it can do an incredible amount of damage i.t.o. data loss.
Of course, regular back-ups and all that… But even with those, the potential havoc / business disruption it can cause…
Is there a way to mitigate it?

1 Like
33

The deactivation hook should never be used to destroy data (or even unset options). That’s what the uninstall hook is for. :wink:

1 Like
34

Plugins generally don’t delete data on deacivation. They would do this on uninstall hooks.

2 Likes
35

A number of plugins have a tickbox option to delete settings or data on deactivation. If that option had been enabled by the user for any reason, and then CP itself deactivated the plugin (i.e. not at a time of the user’s choosing), then that would be a Bad Thing and CP would deserve the negative publicity that would ensue.

I’d be very wary of a CMS that can deliberately break itself (because that’s what this is) without asking for permission or giving a warning. Hell, I don’t even like it when a hosting company adds a define to wp-config.php without asking me first…

2 Likes
36

Two concerns about this.

While it is definitely best practice to use the uninstall hook as opposed to the deactivation one, I have seen data deletions / unset options upon deactivation (sometimes for valid functional reasons, while others may be because the author is not following best practice).
So, the site owner should know to (and have the skill to) examine exactly what happens when the plugin is deactivated before setting their security options.

Additionally, it is also considered best practice to delete deactivated plugins.
The security experts can chime in here, but from what I have read some exploits can still be used when a plugin is deactivated, but still installed.
So, I assumed that disabling vulnerable plugins includes the whole process from deactivation to deletion.

I really like the idea of a pre-selected fail-over.
I just think that there are a number of contingencies that should be carefully considered to make it safe.
(I also realize that, as Invisnet said, it will be a while before this can become available.)
One of these concerns is that a number of plugins need significant set-up.
So if I selected a fail-over, I need a mechanism to save my preferred settings for the fail-over in such an event.

37

In this case, it would likely be very temporary, but, yes, it is recommended to not leave deactivated plugins lying around.

38

Imagine you support 20-50 WP (CP) sites and they all use a plugin “Lorem ipsum”. For example, for customizing permalinks. One day someone finds a vulnerability and forces its disabling. Permalinks are broken even without flushing rewrite rules. In a late night (timezones, yep) all of your sites are going down, building mad sitemaps, responsing 404 to indexed links etc. And crawlerbots joyously considering all that. (Keep in mind that some of you clients spend $500-2000 per month on SEO in highly competitive niches achieving the results with tiny steps, spending years to become a leader). Well, in the early morning your phone suddenly rings 20-50 times. Your clients have some questions about what the heck is going on. They are upset or really angry. And you say: “Oh… Well… I don’t know… Maybe someone disabled some plugins to save us from potential threats…”. Even writing this story makes my fingers tremble. It would be a ******* disaster, I think :slight_smile:

So there is really no choice. Ruining one’s site to protect him from hypothetical harm is absolutely unacceptable. I’m not sure if it is even acceptable with direct user permission.

The only proper action in that case is notification + quick fix. Throw a message, send email, mark plugin with a red background, send SMS, shout at my window — whatever. But don’t even think to disable something on my site. I am responsible for it’s health (financial risks, reputational risks) and l have to make all related decisions myself depending on concrete situation and priorities. CP should never perform any actions without direct user request.

P.S. 99% of vulnerabilities I deal with are not risky and absolutely not urgent. Those threats are rather theoretical. And none of them could break all my sites at once like the offered security measures. I usually have plenty of time to fix a problem in a calm manner or even wait till security update releases. Talking honestly, it’s cheaper to restore backups rather then building an “absolute” protection for each potential threat in most cases. The real troublemakers for small projects are usually not “hackers”, but “protectors”. And a human factor, for sure.

P.S. Personally, I think that if project really needs HIGH security level, it should not use WP at all. It should use a custom CMS (no public exploits available, no third-party code etc), secure hosting, cryptography etc. I’d say these sites are often static and have no usual CMS at all (pages are generated in local environment, one-way channel). So when we talk about “high security” we usually mean an average hygienic things, and not paranoic-alike situations where each vulnerability is absolutely critical and requires heroical emergency rushes.

In fact there are vulnerabilities on my sites. Plenty of them, always. And it’s ok. Even using my nickname as a login is quite insecure. But all that stuff is theoretical. In practice, 0,0001% chance of a small trouble is not worth limitation of freedom to avoid it.

9 Likes
39

Just reading about it made me need a large whisky! I agree… this scenario should never happen. I am the only one who makes decisions about my sites - it’s my responsibility and I don’t want any third party doing stuff for me. As @anon95694377 points out, there are now some hosting companies doing just that, but I wouldn’t go near them.

4 Likes