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

81–90 of 244 posts

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

#81

Post by wahnfrieden »

Nextgrid wrote: post #77
doesnt_know wrote: post #70

Earlier quoted context omitted.

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 "Authoriz…

It is a national security concern more than a business ownership & market concern

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

#82

Post by musicnarcoman »

curuinor wrote: post #50
tadfisher wrote: post #32

Earlier quoted context omitted.

But do you still store your GH API private key in environment variables?

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

So the CodeRabbit application with access to application secrets still runs in the same virtual machine as untrusted code from the outside?

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

#83

Post by Lionga »

sciencejerk wrote: post #35

I think that Security fuckups of this disastrous scale should get classified as "breaches" or "incidents" and be required to be publicly disclosed by the news media, in order to protect consumers. Here is a tool with 7,000+ customers and access to 1 million code repositories which was breached with an exploit a clever 11 year old could created. (edit: 1 million repos, not customers) When the exploit is so simple, I f…

Code Rabbit is a vibe coder company, what would you expect? Then they try to hide the breach and instead post marketing fluff on google cloud blog not even mentioning they got hacked and can not even give any proof there is no backdoor still running all the time.

What a piece of shit company.

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

#84

Post by roywiggins »

Nextgrid wrote: post #77
doesnt_know wrote: post #70

Earlier quoted context omitted.

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 "Authoriz…

In this specific case running linters doesn't even need that much I think, it's never going to need to reach out to GitHub on its own, let alone Anthropic etc. The linter process likely doesn't even need network access, just stdout so you can gather the result and fire that back to GitHub or whenever it needs to go. Just executing it with an empty environment would have helped things (though obviously an RCE would still be bad)

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

#85

Post by Nextgrid »

wahnfrieden wrote: post #81
Nextgrid wrote: post #77

Earlier quoted context omitted.

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 "Authoriz…

It is a national security concern more than a business ownership & market concern

Unless "national security" is going to either pay people proactively to pass gov-mandated pentests, or enforce actual, business-threatening penalties for breaches, it doesn't really matter from a company owner perspective. They're not secure, but neither are their competitors, so it's all good.

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

#86

Post by roywiggins »

yunohn wrote: post #43
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…

While I fully understand that things sometimes get missed, it just seems really bizarre to me that somehow “sandboxing/isolation” was never considered prior to this incident. To me, it feels like the first thing to implement in a system that is explicitly built to run third party untrusted code?

It seems to me that they thought the linter would be safe to run as it wasn't meant to actually run untrusted code, just statically analyze it.

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

#87

Post by 0x457 »

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…

GH Apps already use short-lived tokens that can be scoped per repo. You mint a token using your private key and exchange it for a token via API. Then you use that token and dispose of it. That's the only way to use GH Apps (User Access Tokens which are the same thing, but require user interaction) Those tokens always expire.

I'd rather GitHub finally fix their registry to allow these GH Apps to push/pull with that instead of PAT.

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

#88

Post by mook »

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…

There's also no reason why they needed to have write access to post code review comments. But for some reason they ask for it and you can't deny that part when hooking up their thing.

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

#89

Post by roywiggins »

elpakal wrote: post #7
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?

presuming they take the output of running these linters and pass it for interpretation to Claude or OpenAI

It's very silly that the linter process was handed those environment variables, since it wasn't going to do anything with them and didn't need them.

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

#90

Post by jsbg »

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…

wild to comment this
Post reply on HN