Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124813
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 06 Aug 2024 21:05:40 +0200
To: internals@lists.php.net
Message-ID: <ffc9c850-06f1-4937-be55-b9e2cc614dfb@app.fastmail.com>
In-Reply-To: <7d9a9752-a202-4099-a60a-2686d4265d96@gmail.com>
References: <e08f6af322dcc5b4e4dd5e772f28be07ffa07ba4.camel@ageofdream.com>
 <c510eb675bd0038efbbe5489bebd42ff7438e967.camel@ageofdream.com>
 <7d9a9752-a202-4099-a60a-2686d4265d96@gmail.com>
Subject: Re: [PHP-DEV] [Discussion] Sandbox API
Content-Type: multipart/alternative;
 boundary=66733e70d0d6453fbd131b7fa716961c
From: rob@bottled.codes ("Rob Landers")

--66733e70d0d6453fbd131b7fa716961c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Aug 6, 2024, at 20:59, Niels Dossche wrote:
> On 06/08/2024 10:41, Nick Lockheart wrote:
> >=20
> > Sandbox: Security
> >=20
> > A SandBox has two use cases:
> >=20
> > 1. Unit Testing of code with mocks or stubs, and also, allowing test=
ing
> > with different environments.
> >=20
> > 2. The secure running of 3rd party code inside a 1st party applicati=
on.
> >=20
>=20
> The use-case of securely running 3rd party code inside your applicatio=
n is impossible at this moment, and will still be impossible after a san=
dbox API is introduced.
> The reason is that the PHP interpreter as it is today is not memory sa=
fe. It is relatively easy to cause memory corruption by only using PHP c=
ode by abusing things like custom error handlers set from userland. This=
 in turn can be used to gain arbitrary read/write primitives which has b=
een shown to circumvent disable_functions & open_basedir, and some PoCs =
can even run arbitrary commands. It would be doable to extend these tric=
ks to circumvent a sandboxing API.
> As such, a sandboxing API for securely executing 3rd party code is onl=
y possible after the interpreter has become memory safe.
> Although some work has been done in PHP 8.3 to plug many of these memo=
ry safety bugs in the VM, much more work remains and would likely requir=
e complicated changes.
> So therefore I propose to only focus on the mocking functionality of y=
our proposal for now, until the time comes that the interpreter is memor=
y safe.
> I would therefore also not call it "sandbox".
>=20
> Introducing a sandbox API for security also opens up a can of worms fo=
r the security policy.
> Right now we are assuming an attacker model of a remote attacker, and =
that the code running on your server is trusted.
> But that would change when an official sandbox API is introduced.
>=20
> Kind regards
> Niels
>=20
Hey Niels,

I find this assertion kind of scary from a shared hosting perspective or=
 even from a 3v4l kind of perspective. How do these services protect the=
mselves if php is inherently insecure?

=E2=80=94 Rob
--66733e70d0d6453fbd131b7fa716961c
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Tue, Aug 6, 2024, at 20:59, Niels Dossche wrote:<br></=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 06/08/2024 10=
:41, Nick Lockheart wrote:<br></div><div>&gt;&nbsp;<br></div><div>&gt; S=
andbox: Security<br></div><div>&gt;&nbsp;<br></div><div>&gt; A SandBox h=
as two use cases:<br></div><div>&gt;&nbsp;<br></div><div>&gt; 1. Unit Te=
sting of code with mocks or stubs, and also, allowing testing<br></div><=
div>&gt; with different environments.<br></div><div>&gt;&nbsp;<br></div>=
<div>&gt; 2. The secure running of 3rd party code inside a 1st party app=
lication.<br></div><div>&gt;&nbsp;<br></div><div><br></div><div>The use-=
case of securely running 3rd party code inside your application is impos=
sible at this moment, and will still be impossible after a sandbox API i=
s introduced.<br></div><div>The reason is that the PHP interpreter as it=
 is today is not memory safe. It is relatively easy to cause memory corr=
uption by only using PHP code by abusing things like custom error handle=
rs set from userland. This in turn can be used to gain arbitrary read/wr=
ite primitives which has been shown to circumvent disable_functions &amp=
; open_basedir, and some PoCs can even run arbitrary commands. It would =
be doable to extend these tricks to circumvent a sandboxing API.<br></di=
v><div>As such, a sandboxing API for securely executing 3rd party code i=
s only possible after the interpreter has become memory safe.<br></div><=
div>Although some work has been done in PHP 8.3 to plug many of these me=
mory safety bugs in the VM, much more work remains and would likely requ=
ire complicated changes.<br></div><div>So therefore I propose to only fo=
cus on the mocking functionality of your proposal for now, until the tim=
e comes that the interpreter is memory safe.<br></div><div>I would there=
fore also not call it "sandbox".<br></div><div><br></div><div>Introducin=
g a sandbox API for security also opens up a can of worms for the securi=
ty policy.<br></div><div>Right now we are assuming an attacker model of =
a remote attacker, and that the code running on your server is trusted.<=
br></div><div>But that would change when an official sandbox API is intr=
oduced.<br></div><div><br></div><div>Kind regards<br></div><div>Niels<br=
></div><div><br></div></blockquote><div>Hey Niels,<br></div><div><br></d=
iv><div>I find this assertion kind of scary from a shared hosting perspe=
ctive or even from a 3v4l kind of perspective. How do these services pro=
tect themselves if php is inherently insecure?</div><div><br></div><div =
id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--66733e70d0d6453fbd131b7fa716961c--