5 ms·

Wow yikes, kudos to the great disclosure and fix process from homebrew and other involved folks. Github Actions seems like such an easy target--the workflows p

Wow yikes, kudos to the great disclosure and fix process from homebrew and other involved folks. Github Actions seems like such an easy target--the workflows people build are complex, difficult to audit, and lightly or never tested at all except in prod. It's just a recipe for disaster and all these recent issues (see also: https://news.ycombinator.com/item?id=26908076 https://news.ycombinator.com/item?id=26908076) make me wonder if the Github flow model of a wild west of public pull requests just isn't compatible with how people use workflows and automation in practice. No one in their right mind would leave a Jenkins server open for anyone to trigger some workflows. It's silly that everyone effectively does that because they see some Github branding on a page and feel safer.

oefrha 6y ago
> No one in their right mind would leave a Jenkins server open for anyone to trigger some workflows. Open source projects have been doing exactly that for ages. Homebrew in particular had a Jenkins server hosted at bot.brew.sh running arbitrary pull requests since 2013 before finally fully migrating to GitHub Actions in 2020.
- alfiedotwtf 6y ago
  Not only this, but public Jenkins often have their shell open to the public!
- capableweb 6y ago
  > Open source projects have been doing exactly that for ages. I'm not sure it's that common. What's common is to allow people to browse the Jenkins instance, but disable anything to run PRs that changes the workflow/build itself from people who are not part of the organization/team that manages Jenkins.
  - oefrha 6y ago
    You don’t need to make changes to workflows to run arbitrary code. Projects usually run tests, and you can just put whatever you want to execute in the code being tested, or exploit other holes in the existing workflow. TFA does not make any changes to existing workflows, for instance. Also, you can disable workflow changes in GitHub Actions with the pull_request_target event, in which case it uses the workflow definition from the target branch.
    - Master_Odin 6y ago
      The pull_request_target event however allows for read/write access to the base repo and access to all of its secrets. It's not the event type you'd want to use whenever dealing with code that's incoming in a PR. See the big warning at https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request_target https://docs.github.com/en/actions/reference/events-that-tri....
      - oefrha 6y ago
        That’s not true at all. Unless you expose the token or secrets in steps where you run untrusted code, the token and secrets are safe. This is explicitly designed for untrusted pull requests on public repos, solving the problem of, say, adding labels with the write token, or deploying a preview build to Netlify, while keeping the secrets safe from arbitrary code execution.
- sneak 6y ago
  Running arbitrary code from users in CI is one thing. Automatically merging code is another, which is what this bug exploited. The former can be made somewhat/reasonably safe. The latter probably can't.
  - oefrha 6y ago
    Yes, but that is not what this thread (GitHub Actions is somehow more vulnerable than Jenkins because no one exposes Jenkins?) is about.
TreeInBuxton 6y ago
This is exactly why on a project I recently set up CI on, it is only run when a collaborator gives an approving review, or something is pushed directly to master. I saw far too much of an attack surface from Github actions, especially with MSBuild.

oefrha 6y ago

> No one in their right mind would leave a Jenkins server open for anyone to trigger some workflows. Open source projects have been doing exactly that for ages. Homebrew in particular had a Jenkins server hosted at bot.brew.sh running arbitrary pull requests since 2013 before finally fully migrating to GitHub Actions in 2020.

alfiedotwtf 6y ago
Not only this, but public Jenkins often have their shell open to the public!
capableweb 6y ago
> Open source projects have been doing exactly that for ages. I'm not sure it's that common. What's common is to allow people to browse the Jenkins instance, but disable anything to run PRs that changes the workflow/build itself from people who are not part of the organization/team that manages Jenkins.
- oefrha 6y ago
  You don’t need to make changes to workflows to run arbitrary code. Projects usually run tests, and you can just put whatever you want to execute in the code being tested, or exploit other holes in the existing workflow. TFA does not make any changes to existing workflows, for instance. Also, you can disable workflow changes in GitHub Actions with the pull_request_target event, in which case it uses the workflow definition from the target branch.
  - Master_Odin 6y ago
    The pull_request_target event however allows for read/write access to the base repo and access to all of its secrets. It's not the event type you'd want to use whenever dealing with code that's incoming in a PR. See the big warning at https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request_target https://docs.github.com/en/actions/reference/events-that-tri....
    - oefrha 6y ago
      That’s not true at all. Unless you expose the token or secrets in steps where you run untrusted code, the token and secrets are safe. This is explicitly designed for untrusted pull requests on public repos, solving the problem of, say, adding labels with the write token, or deploying a preview build to Netlify, while keeping the secrets safe from arbitrary code execution.
sneak 6y ago
Running arbitrary code from users in CI is one thing. Automatically merging code is another, which is what this bug exploited. The former can be made somewhat/reasonably safe. The latter probably can't.
- oefrha 6y ago
  Yes, but that is not what this thread (GitHub Actions is somehow more vulnerable than Jenkins because no one exposes Jenkins?) is about.

TreeInBuxton 6y ago

This is exactly why on a project I recently set up CI on, it is only run when a collaborator gives an approving review, or something is pushed directly to master. I saw far too much of an attack surface from Github actions, especially with MSBuild.