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
