GitHub Actions checkspelling community workflow GitHub_TOKEN leakage via symlink

129 点作者 pentestercrab超过 3 年前

11 条评论

OJFord超过 3 年前

I don't know why it hasn't occurred to me as a problem before, but branches/PRs can also modify the workflow, and their build runs the new modified workflow... I must be missing something, because that seems to make it way worse, forget symlinks and project-specific vulns, just print the env? Has modifying the workflow on a 'PR branch' only worked for me because I've been the repo owner perhaps?Edit to add: I think what I'm missing (haven't fully understood yet, just thought should share) is the importance here of the 'pull_request_target' event type used. The docs carry a warning:> Warning: The pull_request_target event is granted a read/write repository token and can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch, and to help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see "Keeping your GitHub Actions and workflows secure: Preventing pwn requests" on the GitHub Security Lab website.<a href="https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request_target" rel="nofollow">https://docs.github.com/en/actions/reference/events-that-tri...</a>

评论 #28468564 未加载

评论 #28471678 未加载

评论 #28468293 未加载

cmsj超过 3 年前

The more I've used Actions, the more I have come to two conclusions:1) It's generally better to just do things with legacy tooling and your own scripts, than it is to pull in community actions2) GitHub badly needs to implement tightly scoped tokens. GITHUB_TOKEN has a completely fixed and unmodifiable scope, and if you need to give a workflow an OAuth token to perform some other operation, your only choice is to give it a full read-write token for all of the repositories the token's user can access. You can't even scope a token to a single repo, let alone make one that's read-only, or limited to, say, commenting.

评论 #28468358 未加载

arcatek超过 3 年前

I was under the impression that the default temporary GITHUB_TOKEN for forked repos (which is what happens with PRs) were read-only. Isn't that the case?<a href="https://docs.github.com/en/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token" rel="nofollow">https://docs.github.com/en/actions/reference/authentication-...</a>

评论 #28467687 未加载

sgtcodfish超过 3 年前

This is super interesting; we had a fairly long discussion about whether or not to add this action to cert-manager[1], and ended up rejecting it in part because it increased the risk of supply-chain attacks and that risk wasn't, in our opinion, outweighed by the potential benefit of catching more spelling mistakes.[2]For me, I think there's a wider point here that GitHub Actions are pretty scary in terms of these kinds of attacks. Pre-packaged actions are easy to add to a project but come with risks, as this security advisory shows! There are a few aspects to Actions which made me a little uneasy in terms of my threat models when building software, and personally I've tended to avoid them.[1] <a href="https://github.com/jetstack/cert-manager" rel="nofollow">https://github.com/jetstack/cert-manager</a> (Full disclosure, I'm part of the team paid by Jetstack to work on the cert-manager project)[2] <a href="https://github.com/jetstack/cert-manager/pull/3863#issuecomment-872375017" rel="nofollow">https://github.com/jetstack/cert-manager/pull/3863#issuecomm...</a>

kevingadd超过 3 年前

It feels kind of absurd to me that symlinks like this work by default in workflows, if at all. The symlink being able to point outside of the source tree is even worse. Github should be scrubbing anything like this from PRs at a minimum. The only use cases for this stuff I can think of are either absurdly low-quality code (a security risk you absolutely don't want to accept), or attacks.

matsemann超过 3 年前

I've always been a bit vary of running stuff automatically on PRs from untrusted persons. How easy is it to exploit? If my repo always runs all tests on a PR, could someone just add a PR with a new test that is then run? Thus running their arbitrary code.

评论 #28467964 未加载

评论 #28468283 未加载

Waterluvian超过 3 年前

Do spelling checks like this one provide valuable feedback for anyone?I always found they required constant configuration to handle regional language and false positives on valid programming terms.

评论 #28472480 未加载

xucheng超过 3 年前

> Importantly, you must do this for every open branch in your repo. It is not enough to do so for only your default branch since a malicious PR can target any of your open branches. That is, if you have an open branch that uses a vulnerable version of check-spelling then a malicious PR targeting that branch can leak a GITHUB_TOKEN which can then be used to impact any of your branches, including your default branch.I think this is a big design flaw in GitHub Actions. Whenever there is a security patch, you have to make sure to apply them in every branch. This includes all the historical branches and stale branches which the repo owners forget to delete.

评论 #28468955 未加载

评论 #28468025 未加载

hardwaresofton超过 3 年前

Note -- if you're running Github Actions on your local machine, run it in a VM. You can use something like multipass[0] which is pretty light (Ubuntu is heavy of course, but is the expected OS of most setup documentation).While working on a project of mine that runs runners (Github, GitLab and others), how to safely run other people's random workloads and not become a botnet/crypto miner was basically the only hard technical challenge. GitLab is farther ahead in terms of runner sophistication (and also options available to you when self hosting) by a long shot.[0]: <a href="https://multipass.run/docs" rel="nofollow">https://multipass.run/docs</a>

jrochkind1超过 3 年前

So, I get really confused by Github permissions model; I know that sometimes I am forced to give something access to all of my repos when I really only want it to act on one.Does this affect the leaked GITHUB_TOKEN, what would that token give a posessor access to, what's the scope? Just one repo, or many?If the token gives access to, say, every repo that the user who authorized it has access to, this makes the scope of any vulnerability even worse. And vulnerabilities, like bugs, will always happen.I've been wondering for a while how github gets away with such poor scoping of it's auth without more outcry/demand. And figured that maybe it would take an exersized vulnerability to bring attention to it.

评论 #28468799 未加载

vemv超过 3 年前

Probably this info is reflected somewhere in the document (my bad), but is there any specific insight that we can learn for the code we write to avoid similar issues?