Earlier quoted context omitted.
https://www.coderabbit.ai/blog/our-response-to-the-january-2...
Not a single mention of env vars. Just shifting the blame to rubocop.
[deleted]
How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
151–160 of 244 posts
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#152Yikes, this is a pretty bad vulnerability. It's good that they fixed it, but damning that it was ever a problem in the first place.
Rule #1 of building any cloud platform analyzing user code is that you must run analyzers in isolated environments. Even beyond analysis tools frequently allowing direct code injection through plugins, linters/analyzers/compiler are complex software artifacts with large surface areas for bugs. You should ~never assume it's safe to run a tool against arbitrary repos in a shared environment.
I also ran a code analysis platform, where we ran our own analyzer[1] against customer repos. Even though we developed the analyzer ourself, and didn't include any access to environment variables or network requests, I still architected it so executions ran in a sandbox. It's the only safe way to analyze code.
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#153I 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.
Most security bugs get fixed without any public notice. Unless there was any breach of customer information (and that can be often verified), there are typically no legal requirements. And there's no real benefit to doing it either. Why would you expect it to happen?
[deleted]
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#154hey, 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 can you guarantee that nobody ripped the private key before the researcher told you about the issue though?
if they can't guarantee this then every single repo that had coderabbit is potentially compromised
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#155It 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…
A pretty straightforward solution is to have an isolated service that keeps the private key and hands back the temporary per-repo tokens for other libraries to use. Only this isolated service has access to the root key, and it should have fairly strict rate limiting for how often it gives other services temporary keys.
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#156I 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.
Most security bugs get fixed without any public notice. Unless there was any breach of customer information (and that can be often verified), there are typically no legal requirements. And there's no real benefit to doing it either. Why would you expect it to happen?
> Unless there was any breach of customer information (and that can be often verified), there are typically no legal requirements.
If the company is regulated by the SEC I believe you will find that any “material” breach is reportable after the determination of materiality is reached, since at least 2023.
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#157One 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 h…
You should treat running a code analyzer/builder/linter against a codebase as being no safer than running that codebase itself.
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#158Earlier quoted context omitted.
https://www.coderabbit.ai/blog/our-response-to-the-january-2...
For anyone following along in the comments here. Code Rabbit's CEO posted some of the details today, after this post hit HN. The usual "we take full responsibility" platitudes.
I would love to know the acceptable version.
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#159yikes!
Re: How we exploited CodeRabbit: From simple PR to RCE and write access on 1M repos
#160Earlier 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…
That's...literally the way it already works.
There is a master private key that mints expiring limited-use tokens.
The problem was leaking the master private key.