Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120813
MIME-Version: 1.0
References: <PH8PR10MB63375994E22A3A9321C01C60BF37A@PH8PR10MB6337.namprd10.prod.outlook.com>
In-Reply-To: <PH8PR10MB63375994E22A3A9321C01C60BF37A@PH8PR10MB6337.namprd10.prod.outlook.com>
Date: Fri, 14 Jul 2023 02:34:52 +0100
Message-ID: <CA+p1FaamHz=nfa=_bQ+NVg51yoXmnzxfEHpmVNXjaX2pxdCZig@mail.gmail.com>
To: Sergii Shymko <sergey@shymko.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000034f59306006875e7"
Subject: Re: [PHP-DEV] Security implications of parsing env variables in .ini
From: davidgebler@gmail.com (David Gebler)

--00000000000034f59306006875e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 13, 2023 at 10:25=E2=80=AFPM Sergii Shymko <sergey@shymko.net> =
wrote:

> For instance, functions parse_ini_string() and parse_ini_file() do suppor=
t
> the aforementioned env variables syntax, because the underlying code is
> reused. That means that these functions can potentially be exploited to
> read sensitive information!
>
> For example:
> AWS_SECRET_ACCESS_KEY=3DamazonWebServicesSecretAccessKeyExample1 php -r
> 'var_export(parse_ini_string("secret=3D\${AWS_SECRET_ACCESS_KEY}"));'
> array (
>   'secret' =3D> 'amazonWebServicesSecretAccessKeyExample1',
> )
>

If you find any way to exploit this, you've already breached enough to
have sufficient access to read the entire environment available to the PHP
user anyway (for example, you already had a way to inject arbitrary code
into a script which is eval'd or whatever...) in which case, why would you
care about parse_ini_string when you could just e.g. var_dump(getenv())?

--00000000000034f59306006875e7--