Re: [Discussion] Sandbox API

From: Date: Tue, 06 Aug 2024 19:05:40 +0000
Subject: Re: [Discussion] Sandbox API
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-124813@lists.php.net to get a copy of this message
On Tue, Aug 6, 2024, at 20:59, Niels Dossche wrote: > On 06/08/2024 10:41, Nick Lockheart wrote: > > > > Sandbox: Security > > > > A SandBox has two use cases: > > > > 1. Unit Testing of code with mocks or stubs, and also, allowing testing > > with different environments. > > > > 2. The secure running of 3rd party code inside a 1st party application. > > > > The use-case of securely running 3rd party code inside your application is impossible at this > moment, and will still be impossible after a sandbox API is introduced. > The reason is that the PHP interpreter as it is today is not memory safe. It is relatively easy > to cause memory corruption by only using PHP code by abusing things like custom error handlers set > from userland. This in turn can be used to gain arbitrary read/write primitives which has been shown > to circumvent disable_functions & open_basedir, and some PoCs can even run arbitrary commands. > It would be doable to extend these tricks to circumvent a sandboxing API. > As such, a sandboxing API for securely executing 3rd party code is only possible after the > interpreter has become memory safe. > Although some work has been done in PHP 8.3 to plug many of these memory safety bugs in the VM, > much more work remains and would likely require complicated changes. > So therefore I propose to only focus on the mocking functionality of your proposal for now, > until the time comes that the interpreter is memory safe. > I would therefore also not call it "sandbox". > > Introducing a sandbox API for security also opens up a can of worms for 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. > > Kind regards > Niels > 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 themselves if php is inherently insecure? — Rob

« previous php.internals (#124813) next »