Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

research.kudelskisecurity.com

Post reply on HN
Print view View original

61–70 of 244 posts

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#61

Post by thewisenerd »

tadfisher wrote: post #37
thewisenerd wrote: post #28

global scoped installations or keys always scare me for this reason i believe the answer here was to exchange the token for something scoped to the specific repo coderabbit is running in, but alas, that doesn't remove the "RCE" _on_ the repo

They do that, this is how GH apps work. There is no reason to expose the app's private key in the environment for the code that actually runs on the PR.

even if they did not have the PEM file left in the environment, the token is still widely scoped and has the same scope as the PEM

what i'm clearly mis-remembering is being able to exchange the token for a smaller scope e.g., hey~ sign this jwt, with scopes=[org/repo1, org/repo2, permissions=write]

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#62

Post by chanon »

chanon wrote: post #44

Oh my god. I haven't finished reading that yet, it became too much to comprehend. Too stressful to take in the scope. The part where he could have put malware into release files of 10s of thousands (or millions?) of open source tools/libraries/software. That could have been a worldwide catastrophe. And who knows what other similar vulnerabilities might still exist elsewhere.

I'm starting to think these 'Github Apps' are a bad idea. Even if CodeRabbit didn't have this vulnerability, what guarantee do we have that they will always be good actors? That their internal security measures will ensure that none of their employees may do any malicious things?

Taking care of private user data in a typical SaaS is one thing, but here you have the keys to make targetted supply chain attacks that could really wreak havoc.

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#64

Post by immibis »

tadfisher wrote: post #23
brainless wrote: post #5

I did not understand something: why did CodeRabbit run external tools on external code within its own set of environment variables? Why are these variables needed for this entire tooling?

> Why are these variables needed for this entire tooling? They are not. The Github API secret key should never be exposed in the environment, period; you're supposed to keep the key in an HSM and only use it to sign the per-repo access token. Per the GH docs [0]: > The private key is the single most valuable secret for a GitHub App. Consider storing the key in a key vault, such as Azure Key Vault, and making it sign-…

Environment variables used to be standard practice for API keys. It seems like every time someone finds a way to get a key, standard practice gets more convoluted.

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#65

Post by ipython »

curuinor wrote: post #52
thyrfa wrote: post #26

It is incredibly bad practice that their "become the github app as you desire" keys to the kingdom private key was just sitting in the environment variables. Anybody can get hacked, but that's just basic secrets management, that doesn't have to be there. Github LITERALLY SAYS on their doc that storing it in an environment variable is a bad idea. Just day 1 stuff. https://docs.github.com/en/apps/creating-github-apps/a…

hey, this is Howon from CodeRabbit. We use a cloud-provider-provided key vault for application secrets, including GH private key.

This reply, while useful, only serves to obfuscate and doesn’t actually answer the question.

You can store the credentials in a key vault but then post them on pastebin. The issue is that the individual runner has the key in its environment variables. Both can be true- the key can be given to the runner in env and the key is stored in a key vault.

The important distinction here is - have you removed the master key and other sensitive credentials from the environment passed into scanners that come in contact with customer untrusted code??

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#66

Post by [deleted] »

vntok wrote: post #46
mpeg wrote: post #42

Earlier quoted context omitted.

First thing I looked for... this is an absolutely critical vulnerability that if exploited would have completely ruined their business. No bounty!?

Why would they pay anything? The researchers offered them the vuln analysis for free, unprompted. If anything, they got paid in exposure.

[deleted]

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#68

Post by Xunjin »

KingOfCoders wrote: post #30
curuinor wrote: post #25

hey, this is Howon from CodeRabbit here. we wish to note that this RCE was reported and fixed in January. it was entirely prospective and no customer data was affected. we have extensive sandboxing for basically any execution of anything now, including any and every tool and all generated code of any kind under the CodeRabbit umbrella. if you want to learn how CodeRabbit does the isolation, here's a blog post about h…

The chuzpe to use this as PR.

Silicon Valley sitcom comedy moment right here.

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#69

Post by gz09 »

chanon wrote: post #62
chanon wrote: post #44

Oh my god. I haven't finished reading that yet, it became too much to comprehend. Too stressful to take in the scope. The part where he could have put malware into release files of 10s of thousands (or millions?) of open source tools/libraries/software. That could have been a worldwide catastrophe. And who knows what other similar vulnerabilities might still exist elsewhere.

I'm starting to think these 'Github Apps' are a bad idea. Even if CodeRabbit didn't have this vulnerability, what guarantee do we have that they will always be good actors? That their internal security measures will ensure that none of their employees may do any malicious things? Taking care of private user data in a typical SaaS is one thing, but here you have the keys to make targetted supply chain attacks that cou…

Correct me if I'm wrong, but the problem here is not with GitHub Apps, instead CodeRabbit violated the principle of least privilege: ideally the private key of their app should never end up in the environment of a job for a client but rather a short lived token should be minted from it (for just a single repo (for which the job is running)) so it never gets anywhere near those areas where one of their clients has any influence over what runs.

Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos

#70

Post by doesnt_know »

thyrfa wrote: post #26

It is incredibly bad practice that their "become the github app as you desire" keys to the kingdom private key was just sitting in the environment variables. Anybody can get hacked, but that's just basic secrets management, that doesn't have to be there. Github LITERALLY SAYS on their doc that storing it in an environment variable is a bad idea. Just day 1 stuff. https://docs.github.com/en/apps/creating-github-apps/a…

If it’s not a secret that is used to sign something, then the secret has to get from the vault to the application at some point.

What mechanism are you suggesting where access to the production system doesn’t let you also access that secret?

Like I get in this specific case where you are running some untrusted code, that environment should have been isolated and these keys not passed in, but running untrusted code isn’t usually a common feature of most applications.

Post reply on HN