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

71–80 of 244 posts

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

#71

Post by Xunjin »

cleverwebb wrote: post #38
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…

how do you know that no customer data was affected? did you work with github and scan all uses of your keys? how do you know if a use of your github key was authentic or not? did you check with anthroipic/openai/etc to scan logs usage? It's really hard to trust a "hey we got this guys" statement after a fuckup this big

That's why countries should start to legislate on these matters, there are no incentives in focusing on security and properly report to the customers such vulnerability.

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

#72

Post by cube00 »

dpacmittal wrote: post #67

I hope the author received a nice well deserved bounty for this find. Could have been catastrophic in the wrong hands.

When they're spinning it [1] as a PR opportunity with no mention of the breach there won't be a bounty.

[1]: https://news.ycombinator.com/item?id=44954242

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

#73

Post by eranation »

This is very similar to a CVE I discovered in cdxgen (CVE-2024-50611), which is similar to another CVE in Snyk's plugin (CVE-2022-24441). tl;dr if you run a scanner on untrusted code, ensure it doesn't have a way of executing that code.

Some ways to prevent this from happening:

1. Don't let spawned processes have access to your env, there are ways to allowlist a set of env vars that are needed for a sub process in all major languages

2. Don't store secrets in env vars, use a good secrets vault (with a cache)

3. Tenant isolation as much as you can

4. And most obviously - don't run processes that can execute the code they are scanning, especially if that code is not your code (harder to tell, but always be paranoid)

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

#74

Post by iTokio »

That’s why I’m worried about the growing centralization of things such as Chrome, Gmail, AWS, Cloudflare…

It’s very efficient to delegate something to one major actor but we are introducing single points of failure and are less resilient to vulnerabilities.

Critical systems should have defenses in depth, decentralized architectures and avoid trusting new providers with too many moving parts.

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

#75

Post by jacobsenscott »

binarydreams wrote: post #22

I've noticed CodeRabbit at times does reviews that are super. It is able to catch bugs that even claude code misses on our Github PRs. Blows my mind at times tbh. Based on the env vars seems like they're using anthropic, openai, etc. only?

> catch bugs that even claude code misses on our Github PRs

Is that good? I assume it just catches a different 10% of the bugs.

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

#76

Post by risyachka »

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.

Software industry really needs at least some guardrails/regulations at this point.

It is absurd that anyone can mess up anything and have absolutely 0 consequences.

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

#77

Post by Nextgrid »

doesnt_know wrote: post #70
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 is…

If you actually have a business case for defense in depth (hint: nobody does - data breaches aren't actually an issue besides temporarily pissing off some nerds, as Equifax' and various companies stock prices demonstrate), what you'd do is have a proxy service who is entrusted with those keys and can do the operations on behalf of downstream services. It can be as simple as an HTTP proxy that just slaps the "Authorization" header on the requests (and ideally whitelists the URL so someone can't point it to https://httpbin.org/get and get the secret token echoed back).

This would make it so that even a compromised downstream service wouldn't actually be able to exfiltrate the authentication token, and all its misdeeds would be logged by the proxy service, making post-incident remediation easier (and being able to definitely prove whether anything bad has actually happened).

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

#78

Post by filleokus »

gz09 wrote: post #69
chanon wrote: post #62

Earlier quoted context omitted.

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…

I agree, this seems like straight up bad design from a security perspective.

But at the same time, me as a customer of Github, would prefer if Github made it harder for vendors like CodeRabbit to make misstakes like this.

If you have an app with access to more than 1M repos, it would make sense for Github to require a short lived token to access a given repository and only allow the "master" private key to update the app info or whatever.

And/or maybe design mechanisms that only allow minting of these tokens for the repo whenever a certain action is run (i.e not arbitrarily).

But at the end of the day, yes, it's impossible for Github to both allow users to grant full access to whatever app and at the same time ensure stuff like this doesn't happen.

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

#80

Post by lukevp »

filleokus wrote: post #78
gz09 wrote: post #69

Earlier quoted context omitted.

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…

I agree, this seems like straight up bad design from a security perspective. But at the same time, me as a customer of Github, would prefer if Github made it harder for vendors like CodeRabbit to make misstakes like this. If you have an app with access to more than 1M repos, it would make sense for Github to require a short lived token to access a given repository and only allow the "master" private key to update the…

The private key isn’t a key in the “API KEY” sense, it’s a key in the “public/private key pair” sense. It’s not sent to github and there’s no way for them to know if the signing of the token used to make the call happened in a secure manner or not, because github doesn’t receive the key as part of the request at all.
Post reply on HN