How can 'github.ref_name' be attacker controlled?

[ecnepsnai]

Given the following example workflow:

name: "Example"

on:
  push:
    tags: [ "*" ]

permissions:
  actions: read
  contents: read

jobs:
  build:
    name: "Example"
    runs-on: ubuntu-latest
    steps:
      - name: Test
        run: |
          echo "${{ github.ref_name }}"

The use of github.ref_name will be flagged as being possibly attacker controlled, but I'm genuinely curious how?

My understanding is that this value will only refer to either a commit SHA, or a tag name. People without commit rights can't commit tags, so wouldn't that only leave a commit SHA?

[ecnepsnai]

(Great tool, by the way. Workflow security is such an interesting topic to me)

[woodruffw]

Hi @ecnepsnai, thanks for the report and the kind words!

We currently flag github.ref_name because it can be either the tag or branch name when it isn't a SHA ref. In typical workflows the tag won't be attacker controlled, but the branch name could potentially be.

(More generally however, it's also difficult to prove that a tag ref can't be attacker controlled -- a user could theoretically allow external tag creation through a workflow or other automation, and subsequent expansions in a template context would then be attacker controlled.)

TL;DR: we consider it potentially attacker controllable since it can in theory expand to something besides a SHA ref, even if in typical scenarios a dangerous expansion is unlikely.

With that being said, I'm curious if you think this is too sensitive -- one possibility would be lowering the severity for this particular context access, or potentially gating it behind --pedantic (although the latter would require some more thought IMO).

[ecnepsnai]

Ahh I see, I forgot that the ref name could be a branch, and yeah I see how that is attacker controlled.

As for being too sensitive, in my specific example I would say it is, but my example isn't a good representation, I wonder if perhaps zizmor could look at the triggers and determine if its likely to be a risk, and use that to determine if it should or shouldn't flag it?

[woodruffw]

As for being too sensitive, in my specific example I would say it is, but my example isn't a good representation, I wonder if perhaps zizmor could look at the triggers and determine if its likely to be a risk, and use that to determine if it should or shouldn't flag it?

I think this is a great idea, but I don't have a good sense yet for how to make the divisions here 😅 -- one option would be to distinguish between "safe" and "unsafe" workflows (e.g. github.ref_name is probably fine to expand in a push or release event), but these can also be pretty context-sensitive or even indeterminate (e.g. workflow_call is generally unsafe, but there might be a hard-to-analyze condition that limits calls to only safe callers).

I'll leave this open to see if other folks have thoughts on addressing this more generally -- at full generality this looks a lot like the big picture problem of zizmor doing the equivalent of whole program dataflow/control flow, but for GitHub Actions 🙂

[funnelfiasco]

I didn't see this issue when I started discussion #102, but I think the best (from a "make zizmor broadly useful" perspective) approach is to use the WIP ignore functionality in #116 to exclude the cases that you believe to be reasonably safe.

[woodruffw]

Closing in favor of ongoing discussion in #102.

Also for viz: #127 will reduce template-injection's sensitivity by making it aware of safe vs. unsafe expressions. This won't directly impact the github.ref_name case, but it's the first step towards actual flow analysis here.