Disable Vulnerable Plugins

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

2 Likes

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

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.

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

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

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

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

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.

So does this include automatic updates for minor versions?

If you use Softaculous to install WP (hopefully they will decide to start supporting CP soon), you can decide if you want automatic updates, if you only want to update to minor versions, or if you do not want it to automatically update at all.
I would regard a user selection for minor version updates as a direct request?
There is also an option for automatically updating plugins there somewhere.
Personally I do not think that it is alright to override an explicit user rule / preference / selected option. So if they explicitly selected that they DON’T want any automatic updates, I don’t think CP has the right to disregard this.
I don’t think that “direct user request” means everything has to be manual in every instance?

Optional. Default state is discussable. Probably, it should be enabled by default for average user.

My own choice is “no updates until admin asks”. Notifications are ok. This position is specific, but it depends on my typical project lifecycle. In fact it is iterational. Client gets a production version of his site and uses it for some period (~3-6 months) as is, with no changes. Then he shows me a prepared list of required features, changes, notes etc. We discuss clients marketing strategy on next period, review the todo list and produce a new version of a site. Next 1-2 weeks are for tests and debugging. If something (not supercritical) was missed, it goes in todo, but not done immidiately. So everything is usually planed for 1-2 sessions forward and nobody wants any surprises or even spontaneous improvements between fixed releases.

Autoapdates are ok when you support 1-2 websites continiously and monitor changes daily. Otherwise any updates are unwanted, because they potentially break the working cycles and projects queues. Those small events are real chronofags sometimes. Updates are not critical usually, so I prefer to execute them all manually at one time, under control, after a proper backup etc. This works fine for me.

So, I’d like to have an option of “freezing” all updates and related processes. Ideal situaton is when I visit a site once 3 months, look through a list of notifications and proposals, and perform all needed actions at once.

But, again, I understand that my needs are specific and don’t pretend to set default trends.

3 Likes

That’s exactly what I do too! Much better to plan and allow time for checking than to have an update done automatically and find that something has broken at a critical time. (Now that I think of it, that goes for more than just software updates!)

2 Likes

Me too. I want to visit the site immediately after an update and check it out to make sure nothing is broken. I always disable all automatic updates.

3 Likes

Mee to. I run a script that checks for updates and then I update only if I’m sure to have the time to check and eventually fix problems.

Another point is about customers that don’t (want to) pay for maintenance.

An alert on the plugin page (saing something “check what’s happened at this link”) and in the dashboard (check plugin page for alert) is just fine. I don’t like even site health check.

1 Like

I don’t think the default setting as being “off” was ever in question, guys.
Nor do I think either of these gentlemen (or the others involved in these efforts) would override an explicit user preference / instruction.
And, for the record, I agree that I want to have the final choice as to what happens, or does not happen, on sites I control. Obviously others should have that same right.

So, as much as a preference for control over your site is perfectly valid, it does not address the core problem in this particular thread.

Which comes down to:

  1. What can and what should the repository do in the case that plugin vulnerabilities are reported, but left un-patched?
    We have all seen what .org does, or rather does not do, and I think we would agree that such a solution leaves something to be desired.
  2. If the user is given the option of disabling these plugins (which some users may choose to do and one should respect their preferences and autonomy as well), how can this be done safely?

Edit: Also, how is it possible to make sure that plugins with SUCH serious vulnerabilities that they require urgent heroic measures do not make it into the directory in the first place?

1 Like

I still think a mailing list is the best idea, add a nag during the initial setup.

Another idea would be during the update check, if there is a bad plugin installed an all admin notice/alert should be displayed until the plugin is updated/deactivated and it should be non dismissible.

2 Likes

Is there a way to mitigate the risk of people creating dummy sites just to get details on the exploits?

There is a larger issue here: when WP removes a plugin, they provide information that there may be an issue to hackers, without fixing the issue.

Without knowing more about the reasoning behind this decision, I think this is also completely unacceptable. “Security 101” is basically “don’t expose more information than necessary” and this breaks the rule.

Yes: encourage people to practice responsible disclosure, and ideally only disclose issues once a fix is available. This again comes down to ensuring that information about vulnerabilities is simply not available until it can be fixed at the same time.

3 Likes

Is it okay to let people download a plugin you know is vulnerable though?
I think that would open you up to significant legal liability.

What if the plugin owner does not release a fix within a reasonable amount of time?
What is a reasonable time?

We can encourage people to be responsible and that will help a lot.
But we can’t assume that it will always be the case.
And there is currently a very toxic environment around this.

2 Likes

Yep, I think you’ve accurately summed up many of the “hard questions” that we will have to address in these cases.