cache-poisoning when using docker/setup-buildx-action

[mschoettle]

I have the following steps in a workflow which get flagged by zizmor:

- name: Set up Docker Buildx
        uses: docker/[email protected]
      - name: Validate build configuration
        uses: docker/[email protected]

error[cache-poisoning]: runtime artifacts potentially vulnerable to a cache poisoning attack
  --> .github/workflows/docker-build.yml:42:9
   |
40 |         uses: docker/[email protected]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cache enabled by default here
41 |       - name: Validate build configuration
42 |         uses: docker/[email protected]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ runtime artifacts usually published here
   |
   = note: audit confidence → Low

The only thing I can see is that setup-buildx-action has a cache-binary input which the docs state: "Cache buildx binary to GitHub Actions cache backend". And in fact, when I pass false it does not get flagged.

I don't quite understand why in this case there could be a problem with cache poisoning since it is just the binary which is used to build. Could someone please extra context for this particular case?

It seems that #378 is relevant.

[woodruffw]

Hey @mschoettle, thanks for opening a discussion!

I don't quite understand why in this case there could be a problem with cache poisoning since it is just the binary which is used to build. Could someone please extra context for this particular case?

The problem is essentially that the cache poisoning attack is agnostic to whatever is being cached: it doesn't matter whether it's source, an artifact, or a full binary; if it gets executed or turned into an executable product, an attacker can potentially take advantage of it.

In particular, in the docker/setup-buildx-action case, the attacker could poison the cache entry used for the buildx binary and replace it with a compromised copy (or whatever else). The action itself could potentially mitigate this by checking the integrity of the binary after restoring from cache, but I don't think GitHub makes this particularly easy to do (and most actions assume the integrity of the cache).

Let me know if this helps! I'd also be happy to hear thoughts on how to improve the documentation here.

[woodruffw]

NB: A false positive has been fixed here with #644.

[mschoettle]

Thanks for letting me know, I will try it out once the next version is released.

Also, thanks a lot for the explanation above. I found it quite helpful. I think the difficulty that I had was not being able to determine if it is a problem in the particular use case, or not. For that probably have needed to understand better how a cache poisoning attack works. If I understand it right it is a problem when a PR is made from a fork.

[woodruffw]

If I understand it right it is a problem when a PR is made from a fork.

Yep. More specifically, cache poisoning generally starts with an insecure workflow somewhere else in your CI/CD, which the attacker than pivots to your release workflow (to poison the release artifact). That's why the cache-poisoning audit checks for one of two preconditions before flagging a finding: the workflow either needs to have an insecure trigger like pull_request_target, or it needs to perform one of those "release" actions like docker/build-push-action 🙂

[Marcono1234]

the workflow either needs to have an insecure trigger like pull_request_target, or ...

Is this actually implemented though? If I read cache_poisoning.rs correctly (and the integration tests) then only the second case (= "poisoned cache infects release artifact") is covered.

The actual initial "cache poisoning" through a pull_request_target (or similar such as issue_comment, ...?) with performs caching is not covered yet, right? Maybe that would also be worth covering, because a poisoned cache alone is probably problematic enough (e.g. when something like Cacheract is constantly exfiltrating secrets).

[woodruffw]

Yeah, my bad, I misspoke -- we don't check for triggers like pull_request_target as an activator in this audit. Instead, we check for triggers like release and tag pushes with patterns that look like release tags.