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

51–60 of 244 posts

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

#51

Post by wging »

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?

The article seems to imply that something of the sort had actually been attempted prior to the incident, but was either incomplete or buggy. I'm not sure the details would be entirely exculpatory, but unless you want to flatly disbelieve their statements, "not considered" isn't quite right.

> After responsibly disclosing this critical vulnerability to the CodeRabbit team, we learned from them that they had an isolation mechanism in place, but Rubocop somehow was not running inside it.

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

#52

Post by curuinor »

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.

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

#53

Post by curuinor »

cleverwebb wrote: post #36

I had a visceral and (quite audible) reaction when I got to the environment variable listing.

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

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

#54

Post by frankfrank13 »

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…

Reading this, its not clear how your blog posts relates:

1. You run git clone inside the GCR function, so, you have at the very least a user token for the git provider

2. RCE exploit basically used the external tools, like a static analysis checker, which again, is inside your GCR function

3. As a contrived example, if I could RCE `console.log(process.env)` then seemingly I could do `fetch(mywebsite....`

I get it, you can hand wave some amount of "VPC" and "sandbox" here. But, you're still executing code, explicitly labeling it "untrusted" and "sandboxed" doesn't excuse it.

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

#55

Post by cube00 »

edm0nd wrote: post #34

No bounty was paid for this?

I can't say I'm surprised they didn't pay a bounty when they couldn't even own up to this on their own blog [1].

Instead they took it as an opportunity to market their new sandboxing on Google's blog [2] again with no mention of why their hand was forced into building the sandboxing they should have had before they rushed to onboard thousands of customers.

I have no idea what their plan was. They had to have known the researchers would eventually publish this. Perhaps they were hoping it wouldn't get the same amount of attention it would if they posted it on their own blog.

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

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

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

#56

Post by flippyhead »

dpcx wrote: post #18
hahn-kev wrote: post #16

Why does CodeRabbit need write access to the git repo? Why doesn't Github let me limit it's access?

Because it has the ability to write tests for the PR in question.

It's more than that. If can suggest fixes which you can directly commit.

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

#57

Post by flippyhead »

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

Interesting. We removed it as it was mostly too verbose, catching too many false positives and never really added anything useful.

You can comment on this in the PR and supposedly it'll remember and get better.

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

#58

Post by cube00 »

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.

Let's hope the grants keep coming in because those researchers will start getting offers from the darker corners of the web if bounties aren't paid.

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

#59

Post by thyrfa »

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.

Not at that time though, right, considering it was dumped? You have changed since, which is good, but under a year ago had it as just an env var

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

#60

Post by tnolet »

curuinor wrote: post #53
cleverwebb wrote: post #36

I had a visceral and (quite audible) reaction when I got to the environment variable listing.

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

what does that mean? Were the leaked keys irrelevant?
Post reply on HN