Concerns raised about WordPress’ new ‘White Screen Of Death’ protection feature
Security researchers warn that a new feature that will ship with the next version of the WordPress CMS can be abused to disable security plugins and put WordPress sites and blogs at risk.
The feature, which has a very cool name in “WSOD (white-screen-of-death) Protection” and is considered the equivalent of a WordPress Safe Mode, is scheduled to make its debut with the release of WordPress 5.1, expected this spring.
As described by WordPress core developer Felix Arntz, the feature allows WordPress to recognize when a fatal PHP error occurs and what plugin or theme is causing it.
The WSOD Protection feature will pause the plugin or theme’s code and allow the site’s administrator to access the backend panel, where they can investigate and disable the culprit(s) causing the errors.
Image: Felix Arntz
The WordPress team began working on the WSOD Protection feature months ago. The feature is part of a grand master plan to help site owners update from using outdated PHP 5.x servers to using the newer 7.x branches.
The WSOD Protection feature was created at first to allow site owners to recover from site crashes after the PHP 7.x migration, but WordPress developers realized this could also be used to catch errors after updates to WordPress plugins or themes, which sometimes also crash sites in similar ways.
But as the feature took shape and neared completion, several security researchers have realized that it could also be abused.
In a blog post published earlier this week, bug hunter Slavco Mihajloski pointed out that attackers could use low-end and sometimes harmless exploits in WordPress plugins to trigger a fatal PHP error that will be caught by the WSOD protection feature.
Since the WSOD protection feature is designed to pause the faulty plugin’s execution, Mihajloski argues that attackers could abuse it to disable firewalls, two-factor authentication, brute-force protection, and other security-focused plugins installed on WordPress sites.
Mihajloski’s worries were also shared by Matt Rusnak, QA Lead at WordFence. In a bug report discussing the feature, Rusnak also pointed out several other attack scenarios where the WSOD Protection feature would end up helping attackers.
- 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.
- 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.)
- 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.
The WordPress team answered to Rusnak’s feedback with plans to add a new option in the wp-config.php settings file that would allow site owners to disable WSOD Protection. The new option is named WP_DISABLE_FATAL_ERROR_HANDLER.
It is unclear if WSOD protection will ship enabled by default or not when WordPress 5.1 is released, but the feature remains dangerous still, regardless of the addition of the new wp-config.php option.
Security experts recommend that for the time being, site owners only enable it temporarily when updating the PHP server, the WordPress core, or its themes and plugins. Otherwise, keep it disabled.
More security coverage:
READ MORE HERE