GitHub Actions leaking secrets when Miri output is cached

Then proceed to blame Github Actions.

Yes, the root cause here is that it is so easy to write insecure GHA pipelines without noticing.

If you

• Put some secrets into the environment
• Run some arbitrary programs in that environment
• Cache some parts of the output of those programs
• And then make that cache publicly available

then you're doing it wrong. To make this secure, everything running in the environment would have to be carefully audited to not preserve the environment, without even knowing which parts of the environment are sensitive. That's a completely unrealistic expectation. In taint tracking terms, when you ran the program with the secret in the environment, that program's execution is now tainted with the secret, and so is all of its output.

Lucky enough, this is rare -- our ecosystem scan found only a handful of cases where people make secrets globally available to all steps of a pipeline. But you get no indication from GHA that this is a terrible idea, and that is a problem.

This applies even for stdout/stderr: if you put a token into a URL, this can easily end up being printed somewhere. CI providers know this, that's why they filter configured secrets and remove them from the output. They are, basically, removing the taint. (In principle that could be used to actually leak the secret, but with the typical size of secret tokens that is not practical.) But for all other output, this is your responsibility, the CI cannot do it for you.

Now, GHA does provide the knobs to do this properly: you can control which parts of which jobs the secrets are actually exposed to. But it's easy to forget to use these knobs, and that's a fundamental problem of GHA.

(I am a Miri maintainer and author of the patch mentioned in the blog post. I view this patch as defense in depth, similar to stack canaries and ASLR: it's always a bug if you're relying on this 2nd layer of defense, but it's still useful to have.)

I was taught in the 1990s by unix greybeards that environment variables must not be used for sensitive data because they are effectively public: many flavours of unix expose them to all processes via ps, and there are many ways for them to leak much further. Hence programs of that era use files or named pipes (which go through the kernel’s access controls) to provide access to secrets: X, ssh, gpg, etc. So it has been weird to see Heroku and so many subsequent designs depending on such an unsafe mechanism for security-critical information.

What I don't get is: as I understood from their description, the way to exfiltrate the secret from the cache is by force-pushing code that reads them while it runs in CI (and then prints to logs, sends over the network, or something).

But doesn't every CI run have those env variables set anyway, cached or not? (That's how miri picked them up to write them to the cache, after all?) So, can't the force-pushed code just read the env vars directly? As I understand, the only additional thing they get by reading the miri cache is env values from previous runs? Fair enough, this is an information leak (from an older to a newer CI run) that should be fixed; but usually the current env vars are most likely to be valuable. Thus almost every CI setup that cares about this leak (i.e. has sensitive variables) will continue to expose them?