WordPress.org

Forums

Security concern: Inactive themes and plugins can execute code (10 posts)

  1. jsimone
    Member
    Posted 9 months ago #

    I am fairly new to WordPress but not new to websites. I've been managing my current site for about a year, keeping WordPress Core and all my plugins up to date. Then last month I got hacked.

    I still can't say that I have determined the point of entry for sure, but I was SHOCKED! to find out that all the plugins and themes that I am not using can still execute code. This was especially surprising to me since I have gone to the trouble of deactivating everything I am not using.

    Now for the purposes of child themes, in can understand the dilemma of requiring some cross-referencing of folders that are not technically active, but in all other circumstances I can see no excuse for this situation. Heck, WordPress now detects if you are using a child theme, so why even leave any of these themes and plugins in executable directories? At the very LEAST disabled content should be blocked with .htaccess files, and maybe web.config files for the Windows blokes (like me).

    Since I realize that this change would be major enough to possibly break something things, I think version 4.0 is the right time to handle it. For an application that consistently pats itself on the back for how secure it is, this seems like a ridiculous hole to let slide.

  2. all the plugins and themes that I am not using can still execute code.

    That's only partially true. Only a poorly coded plugin or theme functions file built with no best security practices in mind can remotely execute code when deactivated. Can it happen? Sure! Does it happen often? Thank goodness, no!

    In general, if you keep your plugins and themes up to date, you have nothing to worry about. But as a precaution, you should also delete plugins and themes you aren't using, since of course you aren't using them, right? ;)

    Since I realize that this change would be major enough to possibly break something things, I think version 4.0 is the right time to handle it.

    Not really, since WordPress 4.0 is already at Beta 2 and on schedule for release. ;)

    Moving deactivated items to a non-executable directory is indeed an interesting idea though. Follow this guide, and file it as a Feature or Enhancement: http://codex.wordpress.org/Reporting_Bugs

  3. jsimone
    Member
    Posted 9 months ago #

    Only a poorly coded plugin or theme functions file built with no best security practices in mind can remotely execute code when deactivated. Can it happen? Sure! Does it happen often? Thank goodness, no!

    I definitely can't speak to specifics but it worries me that this concern is placed on the shoulders of plugin developers to code every PHP file properly.

    Not really, since WordPress 4.0 is already at Beta 2 and on schedule for release. ;)

    Yes, well, I purposefully left that part out!

    Seriously, I do find this to be a big concern with little downside to fixing. It seems to me that this should be addressed. Thank you for telling me how to report the bug!

  4. jsimone
    Member
    Posted 9 months ago #

    Also, (reading the FAQ) any reason not to report it as a security issue?

  5. I definitely can't speak to specifics but it worries me that this concern is placed on the shoulders of plugin developers to code every PHP file properly.

    If a house is built for me, and it passes code inspection from my city's Department of Housing, who should I blame if it collapses? The builder who constructed the faulty house, or the code enforcement agent whose only job it is to check a list of common concerns?

    Seriously, I do find this to be a big concern with little downside to fixing.

    You're suggesting a major re-write to the plugin and theme system. While an interesting idea, there will be many downsides, as there are with any re-write. :)

    Also, (reading the FAQ) any reason not to report it as a security issue?

    Yes, there are many reasons *not* to report this as a security issue. There is nothing in this particular request which is a undiscovered vulnerability which can be executed immediately to endanger millions of WordPress installations.

    The folks who review the security reports will probably either ask you to file it as a new or enhanced feature or simply pass on it, as their time is spent protecting WordPress users from actionable security threats.

  6. jsimone
    Member
    Posted 9 months ago #

    Piggy-backed on an existing ticket!
    https://core.trac.wordpress.org/ticket/26273

  7. jsimone
    Member
    Posted 9 months ago #

    You're suggesting a major re-write to the plugin and theme system. While an interesting idea, there will be many downsides, as there are with any re-write. :)

    I really don't think this needs to be a big rewrite. It could definitely break things. But my (novice) expectation is it'll mostly break things that people shouldn't be doing anyway.

    (My simplest suggestion is just to rename php file extensions or package things into an archive)

    Checkout the trac ticket if you are interested and thanks for the discussion!

  8. Excellent, looks like there's already some good discussion there. :)

  9. jsimone
    Member
    Posted 9 months ago #

    Here's a nice anecdote to add. I mentioned that my site was hacked last month. It appears certain that the MailPoet extension which I use was the cause.

    This article claims that this exact vulnerability could be exploited without having the plugin enabled. What a coincidence... That fact may be a large part of why this exploit has reportedly affected so many, and why WordPress will again get a lot of the wrong kind of attention.

    http://www.itpro.co.uk/security/22774/50000-sites-hit-by-mailpoet-wordpress-plug-in-security-flaw

  10. Let's keep discussion to the Trac ticket. Those are the people who control if and how something will be implemented.

    https://core.trac.wordpress.org/ticket/26273

Reply

You must log in to post.

About this Topic

Tags