-
-
Notifications
You must be signed in to change notification settings - Fork 6
Description
I'm looking to switch from pre-commit/lite-action to autofix.ci for a variety of reasons, but primarily because autofix.ci seems to have better support for PRs generated by bots (e.g. Renovate).
However, the restriction on workflow names is not ideal. Having a single "autofix.ci" workflow may make sense for a smaller project, but for larger polygot repos, multiple workflows may be needed.
Furthermore, in a repo where status checks are enforced, having a single autofix workflow can limit our ability to selectively enforce which workflows are required to pass.
For the attack vector that is described in https://autofix.ci/security, I'd like to clarify a few details to better understand the actual risk:
Consider a repository with two workflows: autofix.ci and compromised_workflow. We have an attacker that can execute code in compromised_workflow. However, this workflow is locked down to permissions: {contents: read}.
It seems like this is presupposing an existing compromised workflow, correct? I assume so because in a typical setup, you would prevent automatic workflow runs from outside collaborators and you would avoid pull_request_target to prevent running the workflow in the base branch context.
If arbitrary workflow names were allowed, the attacker could upload an "autofix.ci" artifact from the compromised workflow, and then manually call the autofix API. This privilege escalation path is mitigated by requiring that the artifact is uploaded from a specific workflow.
What is the actual risk here? Would autofix apply malicious changes as a commit to the PR that triggered the workflow? How is that risk any different from someone maliciously including the changes in the PR in the first place?
Perhaps I'm misunderstanding the risk here, so I would be very grateful for any clarification. If the security measure remains in place, supporting additional workflow names may require an admin portal to configure additional names, which I realize may be a large ask / out of scope. The reason why I'm curious about the actual security risk is to attempt to offer a more meaningful solution that doesn't require an admin portal.