Hacker News Reader

Comment by jesterpm | Hacker News Reader

My bigger concern with credentials in environment variables is that environment variables are broadly accessed through may different frameworks, libraries, etc. If you can convince a library to give you an arbitrary (or all) environment variables, your credentials are leaked. The developer of that particular library may have never even considered that environment variables might contain sensitive data.

PHP's phpinfo() function comes to mind immediately: https://www.php.net/manual/en/function.phpinfo.php

View on HN

If your threat model is executing untrusted 3rd party code, then you should be vetting them to ensure they're not reading your environment data or anything else nefarious. Otherwise they've already accomplished remote code execution. Why would they need to read your env when they can open a backdoor?

It used to be not-impossible to find public phpinfo.php pages out there put up for debugging purposes. Hopefully people have smartened up to that, but it’s an example of how the data could be exposed without remote code execution.

In any case, defense in depth seems like reason alone to do this.

> Why would they need to read your env when they can open a backdoor?

It's a good question.

But consider, containers are (in modern infra) transient and usually sit in a constrained security context where access to other resources is pretty limited. Meanwhile the login credentials and security tokens are often long-lived and (usually) give broad access to a wide security context.

If you give me a back door to a container, the first thing I would be trying to do is use it to level up my credentials before the container dies. One of the first things I would try is dumping the environment!

But if the secrets were learned via an ephemeral file or through a temporary network connection, and even better if they were exchanged for time limited or single use type tokens, I am really left with both a challenging task to dig them out and / or something of limited value anyway.

I've seen credentials appear in logs from env vars. Logs tend to replicate to a few different systems and are usually less locked down than the app they came from. An attacker could get lucky with logs that live in a less-secure storage bucket or monitoring system.

> I've seen credentials appear in logs from env vars.

Then the blame is on the logging system configuration, not the env vars. Like you sanitize sensitive information out of logs, you should sanitize and not expose environment variables in your logs.

When I’m feeling especially paranoid e.g. regarding a key used for financial transactions, then I’ll compartmentalise the runtime using it with the absolute minimum surface area, talk to that over a message queue or similar async construct, and audit the wazoo out of all usage.

But also note, in such a case the key probably isn’t coming from an environment variable, more likely is a subkey generated by a HSM.

Reply on news.ycombinator.com