If plugin details cleared while activated, "impossible" to deactivate

[Viper007Bond]

This is really low priority, but a bug nonetheless.

If you activate a plugin and then delete (or malform) it's details at the top of it's file, it won't show up on the plugins list anymore. That means you can't deactivate it without deleting the file or whatnot.

This stems from the plugins list being created off the files and then doing a check against each one to see if it's activated (last I looked, could be wrong).

Perhaps a fix would be to start with the activated plugins list and then add to / overwrite it with the found plugins list and use the like plugin basename as the default title.

As I said, really fringe case and low priority. ;)

[jaredbangs]

Hmm... it's interesting to think of the possibilities here for plugins with less than noble intentions.

Based on what you've described above, a plugin could theoretically (upon initial activation) modify and hide itself to prevent removal and then even download / insert a new dummy plugin file that uses the original name.

This could lead to a situation where a user who goes to deactivate the new plugin could be fooled into believing they've done so, when in reality the original plugin would remain active.

I agree that it seems unlikely, and of course it does require that the user downloads and activates the original plugin in the first place, and (in the scenario I described) have relatively "loose" file and directory permissions on their plugin directory, but I doubt that's very uncommon.

Maybe I'm missing something in all this, but my memory isn't bad enough to have forgotten about all the nasty tricks some of those sponsored themes were pulling a while back, and I could see the same thing potentially being done here if the plugin dev were sneaky about it.

[santosj]

If a plugin were going to do that they would just edit the database plugin option to where they would never be able to deactivate the plugin and force deletion. However, the combination of both could be a problem.

Lets say User goes to activate and run the application. Finds out that the plugin was a little sneaky and is "phoning" home or adding content that wasn't agreed upon.

User goes to deactivate, and on deactivation hook, the plugin readds itself to the plugin option activated list and opens itself and does the above bug trick.

For a normal user this might pose a problem. What this needs to take into account is that if the User really wanted to remove such a plugin, they would only need to remove it, instead of deleting it. If it creates any other files, like say in the akismet folder, and activates itself when activated the first time, then this would pose a security risk.

It might pose a greater security risk if the plugin does nothing bad and installed the another plugin that does that job for it. It might be difficult to track down and WordPress might be assumed at fault.

Really, it depends mostly on user lack of technical knowledge.

[jaredbangs]

Yeah, I guess it boils down to the fact that if your file permissions are loose enough to allow plugin code to write and/or modify files you're pretty much screwed in any case, even without this bug(?) / issue.

I wrote a quick proof of concept plugin that does what I talked about above: creates another plugin with the same name, activates it, and then hides itself, so that it appears to the user that they just activated the one they thought they did, and if they try to deactivate, they're really only deactivating the dummy one, while the
original remains active and hidden. I can post it if anyone's interested.

Following up on what santosj said above, it could get even worse and harder to detect. Plugins could have a short line buried within them to download new code and use it to modify some other plugin that the user has already activated (such as akismet) and then clean up its tracks by modifying itself so nothing looks out of the ordinary.

Such behavior can be easily prevented by implementing proper file permissions, but I'm not sure what WP can do about that, other than maybe warn the user if they are open to this vulnerability.

But (getting back to the original bug) it probably would be good for the plugin list to always include active plugins without relying (completely) on the data in the plugin files themselves.

[santosj]

Proposed Fix:

If plugin does not exist any longer, then it should be removed from the active plugins list.

[ryan]

That could result in plugins being deactivated when files are being updated. We saw this all the time with the code that reverted to the default theme when the active themes files went away. That code is gone now.

[darkdragon]

Close this as wontfix then?

There is really nothing that can really be done. Most of the safe plugins are not going to be modifying themselves, only the bad ones. The ones that have auto-updating have explicit permission (or so from accepting the terms) from the user to allow the plugin to update itself.

The only way this would be a problem is if a hacker somehow gained access to the WordPress installation (the user is screwed anyway). There is not sure firewall way of preventing a plugin that a user activated from doing all kinds of stuff.

Any sort of WordPress antivirus would have a fun time, but probably would have to be a plugin anyway.

I would suggest a patch if somehow this should be reopened, but the only solution I can see wouldn't be acceptable.

[DD32]

I just ran into this problem on windows, Well, a similar problem.

On filesystems that are not case-sensitive(ie. windows), its possible to rename an active plugins filename/folder and WordPress still load it, However, The plugins list will list it as NOT being active, as the case-sensitivity of in_array() kicks in.

I've attached a patch which will deactivate a plugin if it is in the active plugins list, but doesnt show up on the plugins list. It fixes my problem, and it also fixes this tickets problem when the plugins metadata is messed with.

It does rely on the user visiting the plugins page though, but thats not too much of a problem IMO.

A real-bad plugin would simply latch onto the deactivate hook and re-activate itself however. But this does prevent accidental meta-data removal and filename changes.

[DD32]

deactivate plugin even if plugin list empty

[DD32]

I got to thinking after adding the files, Another option would've been to add dummy-rows for the plugins which are in the active list, but not on the plugins list, ie, add 'badPlugin.php' the name of a plugin on the row and let it be manually deactivated.

[darkdragon]

This is cool. It would clean up the active plugins list, if you forgot to deactivate a plugin before deleting the files. That way, it isn't activated automatically if you add the files back.

Can this go in? The second patch doesn't seem like it will have a major impact. If not then probably need to bump to 2.6 and get a patch in early so that it can be tested and fixed quick enough.

[DD32]

It would clean up the active plugins list, if you forgot to deactivate a plugin before deleting the files.

That allready happens elsewhere in the code (The include plugin files code i believe)

The second patch doesn't seem like it will have a major impact

I should've added a comment about this. the 2nd patch is a correction of a logic error in the first patch.

If the plugins list is empty then the first patch doesnt deactivate any plugins that are loaded still somehow (ala metadata gone missing).

The 2nd patch will deactivate all the plugins if the plugin list is empty.

[santosj]

The plugin data is automatically cleared when the data is malformed in the administration plugins panel. Meaning that the plugin will already be deactivated.