one for the collection

Spin up the container, make sure the register_argc_argv is set and try it out. Success! Further exploitation is left to the reader.

I'm starting from the PHP docker container, and building an exploit script where I copy all the relevant methods from above, get rid of dependencies and unnecessary stuff and check, whether I can supply the value returned in the environment check. Please excuse my PHP, it's not my first language.😶‍🌫️

The getEnvironmentArgument method just loops through the given $args array and checks whether the environment is supplied via "--env". If it succeeds, the value is passed back and set as the application environment. Time to build a proof of concept.

In the EnvironmentDetector, we're entering the $consoleArgs === true condition, which calls detectConsoleEnvironment using the value(s) loaded from $_SERVER['argv']. This in turn calls getEnvironmentArgument.

Continuing by searching the Application.php for the vulnerable code we can see the following. The environment of the Application is detected using the $args just loaded from the $_SERVER global variable.

And that by not much. Besides the obvious version bump, there's a new check. Instead of just setting the $args to the $_SERVER['argv'], which here could include GET params we set, it checks whether we're "runningInConsole" which – surprise – determines if we're running in the console.

To begin the research, I download two versions of the framework, before and after the already existing patch. I choose 6.20.45 and 6.20.44, as this version is old and the new version probably won't include many new features. Download, unzip and diff. Only one file is different: Application.php

Online sources tell us that it has something to do with "register_argc_argv", which tells PHP whether to declare argc and argv variables "that would contain the GET information". This is interesting, given the vulnerability could be used to change environment variables.