3 ms·

Then perhaps you shouldn’t be doing that? Or if the position is that environment variables are suitable to hold secrets, the php folks should document the phpin

Then perhaps you shouldn’t be doing that? Or if the position is that environment variables are suitable to hold secrets, the php folks should document the phpinfo function as a security risk and something that should not be available to unauthenticated users. Not choosing is not an option, it leads to this ‘max severity score’ ‘vulnerability’.

CableNinja 3y ago
phpinfo is like a very in-depth system info function for php. Its a debugging function, and shouldn't be in production code to begin with. The issue i see being exploited is that the owncloud codebase contains this function, and its in the unit/integration tests, which shouldnt be in production code (or should be inaccessible at least). That all being said, the real issue here is that there are sysadmins and devops people who are deploying php.ini configurations to production that allow the use of phpinfo (and probably other functions too), by not explicitly denying those functions, which is totally something the php configuration supports, and is absolutely something that should be done, as there are a number of unsafe php functions. https://www.php.net/manual/en/ini.core.php#ini.disable-functions https://www.php.net/manual/en/ini.core.php#ini.disable-funct...
- tinus_hn 3y ago
  No, the problem is this Shrödinger’s unsafety. If the environment is safe, don’t expose it, functions that expose it are unsafe and should be documented as unsafe and unavailable in production. If the functions are normal, the environment is unsafe, don’t store secrets there. You have to make a choice, it can’t be half of both. That is the real issue.
halJordan 3y ago
Environmental variables have always been available to the environment. Thats the point. Saying dont use them to transmit info is like the hysteria of "dont use the clipboard because any app can access it." Well yeah, the point of the clipboard is ipc. But to your point docker secrets are a thing and have been available for a while. And a publicly exposed phpinfo has been a severe dataleak since before time began. Neither of these are unknown or new. They're just an unfortunate composite enabled by containers.
redserk 3y ago
I agree, but this affects far more than PHP. There are a LOT of projects that use environment variables for secret credentials, and it's especially scary because a number of tools love dumping environment variables. I'd much prefer pulling credentials from a file or pulling down credentials based on properties that the application is oblivious to. There's risks to using files too, but in my experience, environment variables are used a bit more carelessly.

CableNinja 3y ago

phpinfo is like a very in-depth system info function for php. Its a debugging function, and shouldn't be in production code to begin with. The issue i see being exploited is that the owncloud codebase contains this function, and its in the unit/integration tests, which shouldnt be in production code (or should be inaccessible at least). That all being said, the real issue here is that there are sysadmins and devops people who are deploying php.ini configurations to production that allow the use of phpinfo (and probably other functions too), by not explicitly denying those functions, which is totally something the php configuration supports, and is absolutely something that should be done, as there are a number of unsafe php functions. https://www.php.net/manual/en/ini.core.php#ini.disable-functions https://www.php.net/manual/en/ini.core.php#ini.disable-funct...

tinus_hn 3y ago
No, the problem is this Shrödinger’s unsafety. If the environment is safe, don’t expose it, functions that expose it are unsafe and should be documented as unsafe and unavailable in production. If the functions are normal, the environment is unsafe, don’t store secrets there. You have to make a choice, it can’t be half of both. That is the real issue.

halJordan 3y ago

Environmental variables have always been available to the environment. Thats the point. Saying dont use them to transmit info is like the hysteria of "dont use the clipboard because any app can access it." Well yeah, the point of the clipboard is ipc. But to your point docker secrets are a thing and have been available for a while. And a publicly exposed phpinfo has been a severe dataleak since before time began. Neither of these are unknown or new. They're just an unfortunate composite enabled by containers.

redserk 3y ago

I agree, but this affects far more than PHP. There are a LOT of projects that use environment variables for secret credentials, and it's especially scary because a number of tools love dumping environment variables. I'd much prefer pulling credentials from a file or pulling down credentials based on properties that the application is oblivious to. There's risks to using files too, but in my experience, environment variables are used a bit more carelessly.