[wp-trac] [WordPress Trac] #44458: Catch WSODs and provide a means for recovery for end users

[WordPress Trac]

#44458: Catch WSODs and provide a means for recovery for end users
----------------------------------+------------------------
 Reporter:  schlessera            |       Owner:  flixos90
     Type:  task (blessed)        |      Status:  closed
 Priority:  normal                |   Milestone:  5.1
Component:  Bootstrap/Load        |     Version:
 Severity:  normal                |  Resolution:  fixed
 Keywords:  has-patch servehappy  |     Focuses:  multisite
----------------------------------+------------------------

Comment (by WFMattR):

 I was testing the WP 5.1 beta and found some cases where plugins can be
 incorrectly paused. Some could be random, due to reaching the PHP
 memory_limit (depending on varying amounts that core+plugins+themes use in
 a random hit), or a plugin that only uses excess memory in limited
 circumstances could get paused even if it won't actually break the login
 form or wp-admin.

 For login and security-related plugins, pausing the plugins could be worse
 than letting them run normally, especially if the error is only caused by
 bad input from an attack or a bot. I'm most concerned about security
 plugins getting paused (e.g., an attacker could exploit the pausing to get
 a security plugin disabled that's providing the only protection for
 another installed plugin with a known vulnerability), but it looks like it
 could also affect other plugins built for subscribers or other non-admins
 too. Is it possible it could be limited to only parser errors initially,
 or be an opt-in feature?

 (Above is the main question; below are examples of the issues.)

 **Example issues with plugins being incorrectly paused, including
 sometimes affecting security:**

 (I'll attach the sample files referenced below -- I hope this is the right
 place for these.)
 1. **A plugin may be paused because another plugin used a lot of memory.**
 When a site's memory_limit is reached, the plugin that happened to be
 running at the time can be paused, even if it's not using excessive
 memory. That might cause security issues, or may just be confusing for the
 admin, since the paused plugin(s) aren't necessarily the cause of the
 issue.
 2. **Local File Inclusion vulnerabilities in any plugin/theme will give
 the attacker the ability to pause many plugins at will.** When any
 plugin/theme is vulnerable to "Local File Inclusion (LFI)", an attacker
 often cannot use that to make changes to the site, but if plugins can be
 paused by WP 5.1 for redeclaring an existing class, an attacker can choose
 specific plugins to pause, even if those plugins are not vulnerable. I've
 included examples for Jetpack, WPS Hide Login, and Akismet, with a demo
 plugin with a simple LFI vulnerability. (There are over 1100 entries on
 Exploit DB at www.exploit-db.com when searching "local file inclusion"
 without quotes -- some are old or are not WP plugins, but it's common
 enough to be a concern.)
 3. **It might be possible that max_execution_time has the same issue as
 memory_limit.** I haven't made a test case yet. On a shared host that is
 running slowly, or any server under heavy load (including during
 intentional DoS or brute force attacks), many of the requests could cause
 timeouts, which could occur in random plugins' code or the theme's code.

 **Test environment:**
 - WordPress nightly build: 5.1-beta1-44575
 - Active plugins: Akismet, Jetpack, WordPress Beta Tester, WP Crontrol,
 Yoast SEO
 - Twentynineteen theme
 - PHP memory_limit: 128M

 **Steps to reproduce the memory_limit issue:**
 1. This issue requires some tuning of the memory used in the first plugin
 file, to reproduce it on a given site. It may occur randomly on sites that
 use memory near the memory_limit.
 2. Install the sample plugins memory-plugin-1.php and memory-plugin-2.php
 -- this is just to simulate high usage of memory by multiple plugins. The
 first plugin uses a lot of memory, and the second plugin uses only a
 little.
 3. Activate the first plugin, and check the error log. The "Memory after
 allocation" should be a few MB below your site's memory_limit. If it's
 not, adjust the value in the plugin file `define('WASTE_MEMORY_MB',
 119);`.
 4. Activate the second plugin -- if it runs out of memory and can't even
 be activated, decrease the memory amount in the first plugin.
 5. Browse around the admin pages, and see if a plugin gets paused. Since
 the second plugin uses a fairly small amount of memory during a hook, it
 gets paused instead of the one that uses large amounts of memory.
     - Yoast SEO's "Search Console" page or the WP dashboard usually
 triggers it for me, but it may vary by site. (There is nothing wrong with
 either page, but they just use some memory.)
     - Depending on how close you are to the memory limit, some ajax calls
 may also trigger it. Jobs in wp-cron might also use higher memory at
 times.

 **Steps to reproduce LFI example:**
 1. Install and activate the "Local File Inclusion Vulnerability Example",
 a single-file plugin: local-file-inclusion-example.php
 2. Install and activate Jetpack, Akismet, and WPS Hide Login (example
 plugins to be paused)
 3. Visit URLs below from another browser without logging in -- normally
 the "Cannot declare class ..." message would only break the attacker's
 pageload (and in these examples, local file inclusion of this type
 normally has no effect on the function of the plugins for other users),
 but in WP 5.1 the attacker can cause these plugins to be paused.
 4. Visit example.com/?lfi_example=wp-
 content/plugins/jetpack/class.jetpack.php
     - Jetpack is paused in the backend
     - Message: The plugin caused an error of type E_ERROR in line 27 of
 the file /home/wp/public_html/wp-5.1/wp-
 content/plugins/jetpack/class.jetpack.php. Error message: Cannot declare
 class Jetpack, because the name is already in use
 5. Visit example.com/?lfi_example=wp-
 content/plugins/akismet/class.akismet.php
     - Akismet is paused in the backend
     - Message: The plugin caused an error of type E_ERROR in line 3 of the
 file /home/wp/public_html/wp-5.1/wp-
 content/plugins/akismet/class.akismet.php. Error message: Cannot declare
 class Akismet, because the name is already in use
 6. Visit example.com/?lfi_example=wp-content/plugins/wps-hide-
 login/vendor/composer/ClassLoader.php
     - WPS Hide Login is paused in the back end, including reverting the
 custom login page, so although this plugin normally changes the login URL,
 wp-login.php is accessible again
     - Message: The plugin caused an error of type E_ERROR in line 43 of
 the file /home/wp/public_html/wp-5.1/wp-content/plugins/wps-hide-
 login/vendor/composer/ClassLoader.php. Error message: Cannot declare class
 Composer\Autoload\ClassLoader, because the name is already in use

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