Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[security] Race Condition #27

Open
ForbesLindesay opened this issue Nov 4, 2019 · 0 comments
Open

[security] Race Condition #27

ForbesLindesay opened this issue Nov 4, 2019 · 0 comments

Comments

@ForbesLindesay
Copy link

It's possible (fairly simple) to beat CircleCI and get the credentials first. You can figure out what the next build will be, so it's just a case of finding watching the repository and picking up the VCS revision faster than CircleCI can queue the build, download the relevant docker container, load this plugin, and initiate the request.

I think in general that the approach taken here nearly works. I wonder if you could make it work with:

  1. The build makes a request to auth/circleci/login, along with the user, project, build num etc.
  2. The plugin generates a secret key and a "nonce" and returns them to the CircleCI build.
  3. The build puts the "nonce" on stdout.
  4. The plugin requests the build output and checks for the presence of the "nonce". If it's not found for some time, the authentication attempt times out.
  5. The build makes a second request to auth/circleci/callback with the original details, and the secret key from step 2.
  6. Once the plugin has seen the "nonce" in the output, it can return a new client_token that's valid for the lifetime of the build.

An attacker can easily obtain a secret key + nonce pair, but since they cannot control the log output of the build, they cannot steal the secrets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant