lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 20 May 2019 20:07:53 +0200
From: Imre Rad <>
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 or open_basedir, to have unexpected security
implications (register globals, or simply
violated architectural patterns and ended up in a mess (magic quotes
gpc -

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
( along with a proof of concept
code ( 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