Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub Actions: Consider hardening setup against CVE-2020-15228 #1246

Closed
lukpueh opened this issue Dec 17, 2020 · 7 comments
Closed

GitHub Actions: Consider hardening setup against CVE-2020-15228 #1246

lukpueh opened this issue Dec 17, 2020 · 7 comments

Comments

@lukpueh
Copy link
Member

lukpueh commented Dec 17, 2020

Description of issue or feature request:
#1242 added a GitHub Actions based CI workflow . GitHub Actions has a moderate injection vulnerability (CVE-2020-15228) against which we should consider hardening our setup.

Current behavior:
No particular hardening against CVE-2020-15228

Expected behavior:
Assess necessity and harden against CVE-2020-15228.

@jku proposes a strategy in #1195 (comment) also described in https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

@lukpueh lukpueh changed the title GitHubAction: Consider hardening setup against CVE-2020-15228 GitHub Actions: Consider hardening setup against CVE-2020-15228 Dec 17, 2020
@joshuagl
Copy link
Member

Additional hardening we might consider is in the actions we use.

AFAICT an Action release on the marketplace corresponds to a tag in the repository that publishes the action, which leaves users open to malicious maintainer attacks - tags are not immutable, so a repo owner (or attacker) can replace the tag and point to a malicious version of the action.

GitHub allows us to restrict actions to either: only use actions defined in our org, only allow a predefined list of actions, or allow all actions.

@lukpueh
Copy link
Member Author

lukpueh commented Dec 18, 2020

Good observation, @joshuagl! Here are some ideas to reduce the attack surface:

  • use the commit sha instead of the tag (with the downside of pinning full versions, whereas with tags you can also pin major or minor only)
  • allow only actions created/hosted by GitHub (and maybe popular verified 3rd-party actions)
  • try to use custom shell scripts on the run: keyword instead of non-verified 3rd-party actions where feasible

@trishankatdatadog
Copy link
Member

You guys are really thinking this through. Very impressive! 👏🏽

lukpueh added a commit to lukpueh/tuf that referenced this issue Dec 23, 2020
Re-add coverage publishing on coveralls.io, formerly performed by
Travis CI (prior to theupdateframework#1242), using the coveralls cli tool according
to the documentation:
https://coveralls-python.readthedocs.io/en/latest/usage/configuration.html#github-actions-gotcha

**Considered alternatives:**
- Official coveralls GitHub action, which does not seem to work
  well for Python:
  coverallsapp/github-action#4
  coverallsapp/github-action#30

- Inofficial fork of that action, which seems to work better
  but had issues finding the coverage data in the tests folder,
  or the covered code respectively.
  https://github.com/AndreMiras/coveralls-python-action

Besides aforementioned issues of these actions the use of cli tools
from curated package managers seems slightly preferable over
actions from the GitHub Marketplace (see theupdateframework#1246).

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
@joshuagl
Copy link
Member

joshuagl commented Jan 5, 2021

Another reason to distrust 3rd-party Actions – they can push commits (and tags?) to the repository[1].

Furthermore, possibly due to the underlying shared object storage of GitHub, it seems that git activity on forks may have unintended consequences on the forked repo. So far as I can tell, this is not yet confirmed, but the Caddy Web Server seems to have had a release made – and pushed to the Go module proxy – by a tag being pushed to a fork of their repo[2].

lukpueh added a commit to lukpueh/tuf that referenced this issue Jan 13, 2021
Re-add coverage publishing on coveralls.io, formerly performed by
Travis CI (prior to theupdateframework#1242), using the coveralls cli tool according
to the documentation:
https://coveralls-python.readthedocs.io/en/latest/usage/configuration.html#github-actions-gotcha

**Considered alternatives:**
- Official coveralls GitHub action, which does not seem to work
  well for Python:
  coverallsapp/github-action#4
  coverallsapp/github-action#30

- Inofficial fork of that action, which seems to work better
  but had issues finding the coverage data in the tests folder,
  or the covered code respectively.
  https://github.com/AndreMiras/coveralls-python-action

Besides aforementioned issues of these actions the use of cli tools
from curated package managers seems slightly preferable over
actions from the GitHub Marketplace (see theupdateframework#1246).

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
@joshuagl
Copy link
Member

joshuagl commented Feb 9, 2021

GitHub's Security Lab have published some research and recommendations on securing GitHub Actions workflows:

Haven't had chance to dig into this at all, but found an experiment in "Verifiable GitHub Actions" verifyme

MVrachev pushed a commit to MVrachev/tuf that referenced this issue Feb 24, 2021
Re-add coverage publishing on coveralls.io, formerly performed by
Travis CI (prior to theupdateframework#1242), using the coveralls cli tool according
to the documentation:
https://coveralls-python.readthedocs.io/en/latest/usage/configuration.html#github-actions-gotcha

**Considered alternatives:**
- Official coveralls GitHub action, which does not seem to work
  well for Python:
  coverallsapp/github-action#4
  coverallsapp/github-action#30

- Inofficial fork of that action, which seems to work better
  but had issues finding the coverage data in the tests folder,
  or the covered code respectively.
  https://github.com/AndreMiras/coveralls-python-action

Besides aforementioned issues of these actions the use of cli tools
from curated package managers seems slightly preferable over
actions from the GitHub Marketplace (see theupdateframework#1246).

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
@jku
Copy link
Member

jku commented Nov 4, 2021

I'd like to close this:

  • the specific issue that started it has been fixed by github (add-path and set-env commands no longer exist)
  • I've spent time looking at Github actions and have come up with two minor improvements: github actions: set workflow permissions to read-only #1662 and GH actions: limit GitHub token visibility #1652. otherwise the setup seems solid to me
  • using tags for actions does sound a little fishy -- but for the official github actions it seems reasonable: we've made the decision to trust github so we trust their tags to point to right places as well
  • verifying the build environment and making it auditable sounds potentially interesting but I think it should not be handled in this issue: please file specific issues if you think there's something we should do

That leaves us with (I think) just some configuration, like allow only actions created/hosted by GitHub: I think this makes sense since we currently only use githubs own actions (and should have a high bar for using actions made by others). Would one of the org admins like to make that call and maybe flick the switch in settings?

@lukpueh
Copy link
Member Author

lukpueh commented Nov 4, 2021

Would one of the org admins like to make that call and maybe flick the switch in settings?

Done!

Thanks for the research and for creating two more specific issues. Closing..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants