Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77670
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.245 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <44AEFF63-5705-44F1-98E6-1958CA0BB95D@ajf.me>
Date: Fri, 26 Sep 2014 14:02:57 +0100
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <DF933D9C-9791-48FB-A537-E10C4292E27B@ajf.me>
References: <CAPv8svUmNokpqyVr3OCXMbp+q9ZmVnhDStw5dbZxWadLtnuksw@mail.gmail.com> <44AEFF63-5705-44F1-98E6-1958CA0BB95D@ajf.me>
To: marius adrian popa <mapopa@gmail.com>
Subject: Re: [PHP-DEV] Cases Where Bash Shellshock Does Not Apply (mod_php, php-fpm )
From: ajf@ajf.me (Andrea Faulds)


On 26 Sep 2014, at 11:48, Andrea Faulds <ajf@ajf.me> wrote:

> On 26 Sep 2014, at 11:46, marius adrian popa <mapopa@gmail.com> wrote:
>=20
>> Maybe we need an official stance about shellshock
>=20
> Do we? As I understand it, this isn=92t a PHP-level vulnerability, and =
I=92m not sure there=92s much we can reasonably do about it. Similarly =
to the Heartbleed bug, control is not in our hands here.

So I did a little research:

1) On many systems, /bin/sh is a symlink for bash
2) popen() uses /bin/sh
3) PHP uses popen() for its backticks, shell_exec, exec, system, =
passthru and proc_open functions.

To cause the bash issue, you just need an environment variable which is =
set from user data.

This means that almost all PHP CGI apps which use any of the Program =
Execution Functions are vulnerable, and possibly many non-CGI apps if =
they do anything which sets the environment variables based on user =
data.

I think it might be worth us putting a statement on the homepage. =
PHP-level vulnerability it isn=92t, but it is a serious one.
--
Andrea Faulds
http://ajf.me/