Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125094
Date: Wed, 21 Aug 2024 14:32:55 -0400
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>
Message-ID: <D397BAC6-7E88-4B0C-A06D-84CAFB5454C9@getmailspring.com>
In-Reply-To: <CAPyj-LB+7AjEXuG4YYX6HhuzxhS-chM7bz8Nwa5cM5TA1HYaRA@mail.gmail.com>
References: <CAPyj-LB+7AjEXuG4YYX6HhuzxhS-chM7bz8Nwa5cM5TA1HYaRA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order
 (global, then local)
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66c632d7_238e1f29_f01f"
From: john@coggeshall.org (John Coggeshall)

--66c632d7_238e1f29_f01f
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



On Aug 21 2024, at 2:10 pm, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
> Including a malicious composer package already allows for arbitrary
> code execution, do you really need more than that?
>

Of course. We've seen many examples in the wild of 3rd party libraries getting hijacked to inject malicious code (e.g. the whole xz attack). This behavior in PHP is not obvious, and provides a way to covertly target and hijack specific highly sensitive functions without an obvious way to detect it -- while otherwise behaving exactly as a developer would expect.
Why possibly would we want to make it easier to perform such an attack, which as Illija pointed out is actually making PHP slower, in the name of backward compatibility? Defense in depth is a cornerstone of application security.
John
--66c632d7_238e1f29_f01f
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Aug 21 2024, at=
 2:10 pm, Ilija Tovilo &lt;tovilo.ilija=40gmail.com&gt; wrote:</div><bloc=
kquote><div><br><div>Including a malicious composer package already allow=
s for arbitrary</div><div>code execution, do you really need more than th=
at=3F</div></div></blockquote><div><br><div>Of course. We've seen many ex=
amples in the wild of 3rd party libraries getting hijacked to inject mali=
cious code (e.g. the whole <code>xz</code>&nbsp; attack). This behavior i=
n PHP is not obvious, and provides a way to covertly target and hijack sp=
ecific highly sensitive functions without an obvious way to detect it -- =
while otherwise behaving exactly as a developer would expect.</div><br><d=
iv>Why possibly would we want to make it easier to perform such an attack=
, which as Illija pointed out is actually making PHP slower, in the name =
of backward compatibility=3F Defense in depth is a cornerstone of applica=
tion security.</div><br><div>John</div></div>
--66c632d7_238e1f29_f01f--