Provide opt out option for the git auth proxy

Issue #18229 new
Graham Gatus
staff created an issue

Some feedback about the git auth proxy (which allows pushing back to your repository without any additional configuration) is that it opens an avenue for a potential attacker to commit back to a repository. Under such a scenario, either a compromised Docker image or tool executed as part of the build process would attempt to commit back to a repository. Without user vigilance, such a change could go unnoticed.

Current mitigations include:

  • Applying branch restrictions if there is concern about malicious parties attempting to write back to a repository.
  • Cryptographic verification of untrusted third party tools (e.g verifying SHAs/digests of Docker images).
  • Code review process to ensure untrusted tooling is not introduced into the pipeline.

As it stands, we would suggest verification of any tooling used in a build, as a poisoned tool can already 'steal' code, credentials stored in env vars, or write back from any system that has credentials available to do so.

For future work, we could make the git auth proxy 'opt out' via a configuration option in the bitbucket-pipelines.yml file. This would reduce risk of a tool being able to write back, without the need for configuring branch permissions.

Comments (8)

  1. Ryan Bannon

    @Graham Gatus thank you for creating this issue.

    I know I've voiced my concerns in the article, but I'd like to get them on the record in this ticket.

    Regarding the possible solutions mentioned:

    • branch restrictions: This would not work in the case that a BP is using a bot to push back to the repo. For example, we use a bot fairly regularly; most often to tag a commit that passes the build/test step of our pipeline. We also use a bot to update some deployment manifests. The branch restrictions we have in place allow only the bot to make direct commits to the repo; all other commits are allowed by select groups and only by PR merges.

    • cryptographic verification of untrusted third party tools: I'm not sure what you mean here. My concern is more about malicious scripts/code (e.g. a unit test that pushes garbage back up to the repo).

    • code review/user vigilance: Indeed, code review are a BIG part of CI/CD. I agree, reviewers must be vigilant. However, it is my opinion that the new feature has added unnecessary risk for the sake of convenience. Also, I believe the code review argument is potentially dangerous; it sets a precedent that other security holes/issues can be introduced, and the solution is code review.

  2. Log in to comment