Disable Vulnerable Plugins

Projects Directory
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
40

I’m speaking for my own site. I don’t build or manage others’ sites. :wink:

41

Maybe this needs to be approached differently…

So, let’s assume the potential vulnerability is confirmed and the plugin is removed from the directory (temporarily).
The issue with WP was always that users were not notified of this and many continued using vulnerable plugins for a very long time without being any wiser, exposing them to hacks.
There were some plugins that scanned for removals from their repo. Even WF eventually did this. But this could have been for any of a number of reasons, many of which were not actually security related.

I can understand that CP doesn’t want to expose users to that. Particularly in the case of unauthenticated remotely executable vulnerabilities / user privilege escalations that are currently being exploited in the wild (that makes me shudder too).

Usually vulnerabilities will be fixed within a reasonable time and the plugin will be restored to the directory. But too often, this does not happen.

I suggest that the following two less invasive measures be implemented first:

  1. Mandatory disclosure in the change log / a note by the moderator who restored the plugin (the latter being preferable).
    Security experts can decide on the right balance of enough, but not too much, detail.

  2. If a developer does not respond with a fix within a reasonable time, this plugin goes into a special adoption category (qualifies for change of ownership).
    This can have a pre-selected pool of trusted volunteer contributors, who will have first pick if they commit to releasing a fix in a reasonable time.
    It is not a guarantee that all of these plugins will find new homes, but it may be able to help reduce the burden in combination with other measures.
    Plugin owners who monetize their plugins will not want to risk it going up for adoption.

When it comes to disabling:
Again, I can see the appeal of a pre-configured fail-over.
By that I mean, settings that would enable me to say “If plugin Lorem Ipsum has serious vulnerability that is either an unauthenticated, remotely executable vulnerability, or a user-privilege escalation vulnerability which is a zero-day vulnerability currently being exploited in the wild, then: 1. run the following PHP code (that forces a remote back-up of site and whatever else I deem necessary) 2. deactivate / uninstall plugin Lorem Ipsum (depending on preference) 3. install plugin I Like Nice Permalinks 4. use these configuration options for I Like Nice Permalinks.”
That would be the minimum I would need in order to opt-in for something like that.

One of the first things I did was to make sure that this is not the case for me / users.
Personally, I think core should offer the option to force nicknames, instead of making it more difficult by not including it in the default sign-up and requiring you to update the nickname only after registration.