If so, I wonder if there is a legit need for running modified GitHub actions from non-collaborators?
Could also subject modified actions coming in via pull requests (from non-collaborators) to heavy resources constraints and timeouts.
If so, I wonder if there is a legit need for running modified GitHub actions from non-collaborators?
Could also subject modified actions coming in via pull requests (from non-collaborators) to heavy resources constraints and timeouts.
The attack vector in the article is not the main way miners try to steal CPU from the GitHub community. It's just an interesting one that the journalist chose to write about.
IIRC, they already treat the .github folder as a special case; you can't push modifications to workflow files with a personal access token. So why not ensure that an action or workflow will only run if it is checked into the base branch?
That wouldn't stop PRs from modifying scripts that the action runs, but the current behavior seems a bit counter-intuitive.
The threat models are probably more like 1. "make sure only the right people run actions" and separately, 2. "make sure authorized events/actions only use the expected capabilities." Both largely fail today.
The issue is that even if you don’t allow changes to the actual action workflow, running tests gives an attacker the ability to run arbitrary code. They just need to add the code they want to run to the tests (e.g. have the tests mine crypto)
from Microsoft*