Live data from Hacker News

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

research.kudelskisecurity.com

41–50 of 244 posts

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

#41
post #18

Earlier quoted context omitted.

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

Then it should open a PR for those tests so it can go through the normal CI and review process.

Doing that requires write access if you're a Github Application. You can't just fork repositories back into another org, since Github Applications only have the permissions of the single organization that they work with. Rulesets that prevent direct pushes to specific branches can help here, but have to be configured for each organization.

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

#43

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?

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

#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.

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

#45

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…

Where can we find the blog post you made back in January about the RCE fix explaining what measures you took to check if any customer data had been affected?

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

#46
post #42
post #34

No bounty was paid for this?

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.

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

#47
post #24

Earlier quoted context omitted.

It updates the existing PR with the tests, I believe. They'd still get reviewed and go through CI.

Right, the downside being that the app needs write access to your repository.

Writing to PR branches should really be some new kind of permission.

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

#49

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…

> Sandboxing: All Cloud Run instances are sandboxed with two layers of sandboxing and can be configured to have minimal IAM permissions via dedicated service identity. In addition, CodeRabbit is leveraging Cloud Run's second generation execution environment, a microVM providing full Linux cgroup functionality. Within each Cloud Run instance, CodeRabbit uses Jailkit to create isolated processes and cgroups to further restrict the privileges of the jailed process.

In case you don't want to read through the PR

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

#50

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…

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.
Post reply on HN