"PHP is a popular general-purpose scripting language that is especially suited to web development." PHP has deployed several features over the years that are prone to incorrect architectural decisions (safe mode https://www.php.net/manual/en/features.safe-mode.php or open_basedir http://news.php.net/php.internals/105606), to have unexpected security implications (register globals https://www.php.net/manual/en/security.globals.php), or simply violated architectural patterns and ended up in a mess (magic quotes gpc - https://www.php.net/manual/en/security.magicquotes.php). This advisory is about to expand this list: security controls configured via php.ini directives at the PHP_INI_SYSTEM level are ineffective as they could be bypassed by malicious scripts via writing their own process memory on the Linux platform. As an example, a threat actor could exploit this flaw to execute PHP functions that have been disabled via the disable_functions directive. It is quite common to disable the exec family of PHP functions aiming to prevent OS command execution in PHP scripts. This weakness enables executing OS commands in restricted configurations. The attack has been reported to the PHP maintainers (https://bugs.php.net/bug.php?id=78006) along with a proof of concept code (https://github.com/irsl/php-bypass-disable-functions) and the recommendation to introduce a new security measure via the fopen wrappers to prevent tampering with /proc/self/mem. The issue was acknowledged but the proposal was rejected saying the attack could be mounted via PHP extensions as well, and this shall be addressed at the operating system level instead. At this point, I decided to publish this advisory, so that system administrators who rely on php.ini settings as their primary/only line of defense shall revisit their configuration and follow another approaches to secure their applications.
