[wp-trac] [WordPress Trac] #45940: WSOD protection should disable plugins in fewer situations

WordPress Trac noreply at wordpress.org
Fri Jan 11 15:36:42 UTC 2019


#45940: WSOD protection should disable plugins in fewer situations
--------------------------+------------------------------
 Reporter:  markjaquith   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  critical      |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by markjaquith:

Old description:

> [44524] implemented WSOD protection, for #44458. I have concerns about
> how aggressively it pauses plugins.
>
> It is possible to get a plugin paused in the admin by triggering a fatal
> error on the front of the site. Furthermore, that fatal error could be
> triggered by specific user input (maliciously, even). If this is a plugin
> that implements 2FA or SAML or admin event logging or permissions
> filtering or login attempt limiting or any other security- or
> authentication-related function, this could have dire effects on the
> site. Bad actors could have a way of targeting and disabling critical
> site functionality.
>
> I think the scenarios where this pausing occurs should be narrowed. To
> start, I propose that pausing not happen for:
>
> 1. POST requests.
> 2. Requests with a query string other than `?p=X` (or a few other
> standard WordPress query strings we can whitelist).
>
> For example, if a contact form submission, in certain circumstances, can
> result in a fatal error, this should not pause that plugin. If some
> `?obscure-query-arg=BAD_INPUT` URL on a site can result in a fatal error,
> this should not pause the plugin.
>
> If a plugin is taking down the entire site, or preventing a user from
> logging in, **that** is the dead end scenario we'd like to prevent, and
> those are the situations in which it's an acceptable trade-off to pause
> that functionality so that the site owner can take steps to recover more
> gracefully than they could in the past.
>
> See also #45888 which proposes that critical plugins (where the plugin
> itself knows that it's better to take the site down than have its
> functionality disabled) have a way of opting out of WSOD protection.

New description:

 [44524] implemented WSOD protection, for #44458. I have concerns about how
 aggressively it pauses plugins.

 It is possible to get a plugin paused in the admin by triggering a fatal
 error on the front of the site. Furthermore, that fatal error could be
 triggered by specific user input (maliciously, even). If this is a plugin
 that implements 2FA or SAML or admin event logging or permissions
 filtering or login attempt limiting or any other security- or
 authentication-related function, this could have dire effects on the site.
 Bad actors could have a way of targeting and disabling critical site
 functionality.

 I think the scenarios where this pausing occurs should be narrowed. To
 start, I propose that pausing not happen for:

 1. POST requests (on the front end).
 2. Requests with a query string other than `?p=X` (or a few other standard
 WordPress query strings we can whitelist).

 For example, if a contact form submission, in certain circumstances, can
 result in a fatal error, this should not pause that plugin. If some
 `?obscure-query-arg=BAD_INPUT` URL on a site can result in a fatal error,
 this should not pause the plugin.

 If a plugin is taking down the entire site, or preventing a user from
 logging in, **that** is the dead end scenario we'd like to prevent, and
 those are the situations in which it's an acceptable trade-off to pause
 that functionality so that the site owner can take steps to recover more
 gracefully than they could in the past.

 See also #45888 which proposes that critical plugins (where the plugin
 itself knows that it's better to take the site down than have its
 functionality disabled) have a way of opting out of WSOD protection.

--

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


More information about the wp-trac mailing list