fix(actions): prevent command injection in GHA workflow (WPB-9709)

[lwille]

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

This PR fixes a potential command injection in the GitHub Actions workflow of this repository.
A user input (in this case a git tag) was used in a run step without sanitization.

Because of this, a specially crafted tag, e.g. docker/v0.0.0;$(cat${IFS}/etc/passwd)#, could be used to execute arbitrary code in the context of the workflow.

Solutions

Instead of using the unsanitized tag directly, it is passed to the run step as an environment variable. This prevents command execution like in the above example.

Testing

How to Test

This change was tested with the workflow listed below in a separate repository by pushing tags in the shape of 'docker/v0.0.0;$(cat${IFS}/etc/passwd)#'.

Test0 resembles the original workflow of this repo, and Test1 is the fixed version.

An actual test can be made by pushing above tag to a repo with below workflow:

# Example workflow crafted to prove command injection through a crafted semver tag
on:
  push: {}
jobs:
  publish_all:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/[email protected]
        with:
          fetch-depth: 0
      - name: Set tag output
        id: vars
        run: echo "tag=${GITHUB_REF#refs/*/v}" >> $GITHUB_OUTPUT
      - name: Test0
        run: echo ${TAG}
        env:
          TAG: ${{ steps.vars.outputs.tag }}
      - name: Test1
        run: echo ${{ steps.vars.outputs.tag }}

Notes

Exploiting this requires knowledge of the workflow code, execution environment and, most importantly, tag push permission.

Note that git tags are quite restrictive in terms of which characters are allowed, so one cannot just paste a shell script, and that the tag push permission would usually imply that an attacker would already be able to directly modify workflow code.

Nevertheless, as a best practice, we shall try to sanitize any user input that is used in a run step.

---

PR Post Submission Checklist for internal contributors

• Wire's Github Workflow has automatically linked the PR to a JIRA issue

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

• https://wearezeta.atlassian.net/wiki/spaces/SC/pages/1216053328/How+to+avoid+Command+Injection+via+Github+Actions+or+CI+jobs+in+general
• https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#example-of-a-script-injection-attack

[fisx]

thanks!

[lwille]

thanks for the review & merge @fisx !