[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAPWzz4yiBuRH8QZ6sUU7MKSoUbesDoMB050EeEX-QmB1v447YA@mail.gmail.com>
Date: Mon, 20 May 2019 20:07:53 +0200
From: Imre Rad <radimre83@...il.com>
To: bugtraq@...urityfocus.com
Subject: Advisory: security controls configured in php.ini could be bypassed
on Linux
"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.
Powered by blists - more mailing lists