|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #71607 putenv/getenv parameters are passed to subrequests
Submitted: 2016-02-16 07:51 UTC Modified: 2016-02-18 14:00 UTC
Avg. Score:4.1 ± 1.3
Reproduced:12 of 12 (100.0%)
Same Version:4 (33.3%)
Same OS:5 (41.7%)
From: oleg at mastak dot fi Assigned:
Status: Analyzed Package: Apache2 related
PHP Version: 5.6.18 OS: Windows 8.1
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
43 + 43 = ?
Subscribe to this entry?

 [2016-02-16 07:51 UTC] oleg at mastak dot fi
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:
echo "DB_SECRET IS=" . getenv('DB_SECRET')."<br>";

script b.php:

echo file_get_contents('http://localhost/a.php');

Actual result:
In my case, I get following output:
array(0) { }


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-02-16 09:02 UTC]
-Status: Open +Status: Analyzed
 [2016-02-16 09:02 UTC]
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.

 [2016-02-16 11:37 UTC] oleg at mastak dot fi
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 13:57 UTC]
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 . 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.

 [2016-02-18 12:43 UTC]
-Type: Security +Type: Documentation Problem
 [2016-02-18 12:43 UTC]
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. 

 [2016-02-18 14:00 UTC] oleg at mastak dot fi
It is enough that there will be information in documentation about that.

Thank you! :)
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 14 23:01:27 2024 UTC