Sec Bug->Doc #71607 [Ana]: putenv/getenv parameters are passed to subrequests

Edit report at https://bugs.php.net/bug.php?id=71607&edit=1 ID: 71607 Updated by: ab@php.net Reported by: oleg at mastak dot fi Summary: putenv/getenv parameters are passed to subrequests Status: Analyzed -Type: Security +Type: Documentation Problem Package: Apache2 related Operating System: Windows 8.1 PHP Version: 5.6.18 Block user comment: N Private report: Y New Comment: Ok, so as it turns out with a member of the Laravel team, with the cached configuration only the first request will be sensitive to this issue. putenv is still not safe in other aspects, but it is out of the scope here. These impacts should be better documented based on the info from this ticket, given it is now open. Thanks Previous Comments: ------------------------------------------------------------------------ [2016-02-16 13:57:37] ab@php.net Usually Linux distros deliver NTS builds based on mpm_prefork, that's what I assumed you were using for the tests. Still several people work with TS builds, though in most cases they build them manually. I haven't worked with Laravel, but it seems that it's being done there for years already https://laracasts.com/forum/?p=460-env-variables-in-shared-hosting-like-hostgator/0 . As for me, it is quite a sub optimal design approach and actually i'm really surprise it's about some framework aiming web :) Normally hosters would disable the functions they don't support or that are dangerous. There are many places that can potentially be seen as such in the shared hosting environment. With documentation - yep, probably this should be documented better. If there are no other comments, I'm going to set the status to "documentation issue" and open the ticket at least for the educational purposes. Thanks. ------------------------------------------------------------------------ [2016-02-16 11:37:35] oleg at mastak dot fi Hello, Yes, on windows I have mpm_winnt, on linux = prefork. Not sure if it works with mpm=worker. I don't need such feature in our program, problem is that frameworks are currently starting to use .env files which pushes sensitive information to environment variables. This includes Laravel and Lumen frameworks, at least. This means that in some situations, on shared hostings, you can get access to information about other client's database. However, I understand your point. I think it is needed to at least put information about this behaviour to documentation. ------------------------------------------------------------------------ [2016-02-16 09:02:49] ab@php.net Thanks for the report. Apache under Windows is always thread safe, mod_winnt. Since you're doing a sub request to another file - the request will be served in another thread, but still in the same process. putenv() modifies the environment of the whole process. At the end of the first request, the environment will be reset. But since the first request is still running, while the sub request is issued - the environment is not yet cleared. Furthermore - it is no difference on Linux, putenv() is not thread safe. Were you using a thread safe Apache module like mpm_worker while testing? Generally, any NTS SAPI will be safe in this regard, and any TS SAPI will have this issue as long as we rely on the C runtime (and i guess that won't change). If you need to use such mechanics in your programs, it would make full sense to choose some NTS SAPI. So I'd tend to mark this ticket as won't fix therefore. Thanks. ------------------------------------------------------------------------ [2016-02-16 07:51:55] oleg at mastak dot fi Description: ------------ Problem is that if php uses putenv function to write environment variable, then same variable is also passed to all requests made from this script. Please, see attached scripts for demonstration: Put scripts a.php and b.php to same folder, let's say: http://localhost/a.php Load script b.php in browser, script will do requests to http://localhost/a.php. It is expected that script a.php should NOT have any enviroment variable, however, it does have access to environment variable, however, $_ENV superglobal is empty. Works only on Windows, I was not able to reproduce it on Linux server. Test script: --------------- script a.php: <?php echo "DB_SECRET IS=" . getenv('DB_SECRET')."<br>"; var_dump($_ENV); script b.php: <?php putenv('DB_SECRET=SECRET'); echo file_get_contents('http://localhost/a.php'); Actual result: -------------- In my case, I get following output: DB_SECRET IS=SECRET array(0) { } ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=71607&edit=1