php.net |  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
Votes:17
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
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: oleg at mastak dot fi
New email:
PHP Version: OS:

 

 [2016-02-16 07:51 UTC] 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) { }


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-02-16 09:02 UTC] ab@php.net
-Status: Open +Status: Analyzed
 [2016-02-16 09:02 UTC] 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 11:37 UTC] 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 13:57 UTC] 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-18 12:43 UTC] ab@php.net
-Type: Security +Type: Documentation Problem
 [2016-02-18 12:43 UTC] ab@php.net
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
 [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: Tue Mar 19 11:01:28 2024 UTC