Live data from Hacker News

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

research.kudelskisecurity.com

91–100 of 244 posts

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

#91
Can someone explain how is this not GitHub's fault that they don't allow the end-user to modify the permissions that all these services require? E.g., fine-grained permission control?

For example, why a tool like this code analysis service would need git write permission access in the first place?

The only consolation here is that it'd be difficult to forge git repositories because of the SHA hash conflicts for any existing checkout, although presumably even there, the success rates would still be high enough, especially if they attack front-end repositories where the maintainers may not understand what has happened, and simply move on with the replaced repo without checking what went on.

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

#92
I cancelled my coderabbit paid subscription, because it always worries me when a post has to go viral on HN for a company to even acknowledge an issue occurred. Their blogs are clean of any mention of this vulnerability and they don't have any new posts today either.

I understand mistakes happen, but lack of transparency when these happen makes them look bad.

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

#93

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.

This is the third or fourth time you’ve spammed this exact comment in response to people’s perfectly legitimate questions. What is this clown-show bullshit?

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

#94
post #83

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.

I got so much heat for calling out that Tea app for being imbeciles who couldn’t bother finishing reading the firebase docs.

People were quick to blame firebase instead of the devs.

Vibrators are so fucking annoying, mostly dumb, and super lame.

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

#95
post #2

> While running the exploit, CodeRabbit would still review our pull request and post a comment on the GitHub PR saying that it detected a critical security risk, yet the application would happily execute our code because it wouldn’t understand that this was actually running on their production system. What a bizarre world we're living in, where computers can talk about how they're being hacked while it's happening. A…

You mean the anthropic model talked about an exploit... the coderabbit system just didn't listen

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

#96
One of the problems is that code analyzers, bundlers, compilers (like Rust compiler) allow running arbitrary code without any warning.

Imagine following case: an attacker pretending to represent a company sends you a repository as a test task before the interview. You run something like "npm install" or run Rust compiler, and your computer is controlled by an attacker now.

Or imagine how one coworker's machine gets hacked, the malicious code is written into a repository and whole G, F or A is now owned by foreign hackers. All thanks to npm and Rust compiler.

Maybe those tools should explicitly confirm executing every external command (with caching allowed commands list in order to not ask again). And maybe Linux should provide an easy to use and safe sandbox for developers. Currently I have to make sandboxes from scratch myself.

Also in maybe cases you don't need the ability to run external code, for example, to install a JS package all you need to do is to download files.

Also this is an indication why it is a bad idea to use environment variables for secrets and configuration. Whoever wrote "12 points app" doesn't know that there are command-line switches and configuration files for this.

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

#97
post #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…

I don't get it, if you're running on linux then just use Landlock LSM inside a VM.

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

#98
post #62
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…

Just don't grant write access to random apps and you are safe.

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

#100
This is a great read, but unfortunately does not surprise me really, it was bound to happen given how people blindly add apps with wide permissions and githubs permissions model.

It amazes me how many people will install github apps that have wide scopes, primarily write permissions to their repositories. Even with branch protection, often people will allow privilaged access to their cloud in github actions from pull requests. To properly configure this, you need to change the github oidc audience and that is not well documented.

When you enquire with the company who makes an app and ask them to provide a different app with less scope to disable some features which require write, they often have no interest what so ever and don't understand the security concerns and potential implications.

I think github need to address this in part by allowing more granular app access defined by the installer, but also more granular permissions in general.

Post reply on HN