[wp-trac] [WordPress Trac] #26273: Deactivated plugins and themes should not execute

[WordPress Trac]

#26273: Deactivated plugins and themes should not execute
----------------------------+------------------------------
 Reporter:  kirrus          |       Owner:
     Type:  enhancement     |      Status:  reopened
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by jsimone):

 I don't really think those comments pertain to the solutions I proposed.
 In fact comment 5 seems a bit out of touch with reality.

     In many server configurations, the user doesn't have direct write
 access to the WordPress files

 If the user doesn't have write access to WordPress files then the entire
 Plugin section is useless. Special file permissions are required for
 installing, updating, deleting,... what's wrong with needing file
 permissions for deactivating? Put another way: Do we really want to
 endorse configurations where WP administrators can't even keep their
 plugins and core install up to date? Isn't that the exact opposite of what
 we are trying to encourage?

 I agree with comment 13 to an extent.

     Sorry, but editing plugin PHP files will not be a feasible solution
 here. That's just too unreliable and risky, and there are too many things
 that can go wrong, given the many different server configurations that
 WordPress has to support.

 Editing PHP '''''code''''' is definitely overkill and unreliable. But
 '''renaming, archiving, or moving plugin files''' would all be
 appropriate, and fairly trivial. Zip files already drive plugin installs.
 What's wrong with packaging them back up when they are deactivated?

 Let me propose an example of what I think is a very viable exploit for
 WordPress today:

 There are at least tens of thousands of WordPress themes out there. There
 are also a lot of third-party websites distributing themes. I think it is
 fair to say that the perception of a theme is that it is fairly
 lightweight and doesn't present the same security concerns as an out of
 date plugin.

 Unsavory characters could obtain some popular or attractive open-source
 themes and (discretely) inject PHP backdoor code.  They could rename the
 themes and upload them to a slew of community websites. Heck the sheer
 number of themes in the wild might make it trivial to just find a few with
 pre-existing issues. Then, botnets could scan websites for the malicious
 theme names and exploit the backdoors for further nefarious deeds. This
 could all be done even without a user ever activating the theme in
 question.

 I think the community is moving toward doing whatever it takes to put
 security front-and-center. Isn't that what introducing automatic core
 updates is all about? I'm sure making that the default setting was a
 contention topic at one point. I think the benefits again outweigh the
 excuses in this case and the problem should be addressed.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26273#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform