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

101–110 of 244 posts

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

#101

Post by codedokode »

immibis wrote: post #64
tadfisher wrote: post #23

Earlier quoted context omitted.

> Why are these variables needed for this entire tooling? They are not. The Github API secret key should never be exposed in the environment, period; you're supposed to keep the key in an HSM and only use it to sign the per-repo access token. Per the GH docs [0]: > The private key is the single most valuable secret for a GitHub App. Consider storing the key in a key vault, such as Azure Key Vault, and making it sign-…

Environment variables used to be standard practice for API keys. It seems like every time someone finds a way to get a key, standard practice gets more convoluted.

A standard practice imho is configuration files. It is better almost in every aspect.

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

#102

Post by criemen »

codedokode wrote: post #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 h…

> Maybe those tools should explicitly confirm executing every external command

This wouldn't work - it's not external commands that's the problem, it's arbitrary code that's being executed. That code has access to all regular system APIs/syscalls, so there's no way of explicitly confirming external commands.

Python/pip suffers the same problem btw, so I think that ship has sailed.

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

#103

Post by codedokode »

criemen wrote: post #102
codedokode wrote: post #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 h…

> Maybe those tools should explicitly confirm executing every external command This wouldn't work - it's not external commands that's the problem, it's arbitrary code that's being executed. That code has access to all regular system APIs/syscalls, so there's no way of explicitly confirming external commands. Python/pip suffers the same problem btw, so I think that ship has sailed.

Then explicitly confirming running every hook with displaying module and function name.

> Python/pip suffers the same problem btw, so I think that ship has sailed.

If I ever find time to write a package manager for C, it won't support hooks.

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

#104

Post by progbits »

immibis wrote: post #64
tadfisher wrote: post #23

Earlier quoted context omitted.

> Why are these variables needed for this entire tooling? They are not. The Github API secret key should never be exposed in the environment, period; you're supposed to keep the key in an HSM and only use it to sign the per-repo access token. Per the GH docs [0]: > The private key is the single most valuable secret for a GitHub App. Consider storing the key in a key vault, such as Azure Key Vault, and making it sign-…

Environment variables used to be standard practice for API keys. It seems like every time someone finds a way to get a key, standard practice gets more convoluted.

It's not convoluted. Env vars are fine for places where you need the value. If your application talks to service X with API key then sure, give it that via env var (mounted from some secret manager, so it's only mounted in production).

But there are two very wrong things here:

1. You don't send the private key to github like an API key, you use it to sign requests. So there is no reason for any application, even your trusted backend, to ever see that key. Just have it request signatures from a vault, and the vault can log each access for audit etc.

2. Even if you really trust your backend and give it the key, why the fuck does the sandboxed runner get it? And don't tell me it's easy to make a mistake and accidentally inherit it somehow. The runner should be on completely separate node, separate network, everything, it only gets the untrusted code to run as input and nothing more, and gives output back.

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

#105

Post by kmarc »

My nightmare is that one of those auto updating vim/vscode/your-favorite-IDE plug-ins That many of us happily use on all the monorepos we work on, at one point invoke a "linter" (or as in this case, configure a linter maliciously) and we start leaking the precious IP to random attackers :-(

In fact, I use rubocop every day lately LOL

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

#106

Post by ianbutler »

If you're a concerned user and you're looking for a solution founded by 2 people with a security background who have sandboxed execution (and network limited) so stuff like this can't happen you should check us out.

We even offer a self hosted deployment which sidesteps this entirely. (feel free to reach out).

www.bismuth.sh

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

#107

Post by progbits »

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…

> no customer data was affected

Someone could have taken the private github key and cloned your customers' private repos.

You would need to audit every single access to github made via your app since the beginning and link it somehow to your side. Did you do this?

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

#108

Post by kmarc »

pengaru wrote: post #79

This third party app gets write access to your repository, so it can do automated reviews of PRs? Why would you even grant it such permissions? this is ridiculous.

Besides that this was clearly a security f*ckup, in my mind it's almost equivalent to running those third party liters in our Internet-connection-enabled editors and IDEs. Other than one banking project, I don't think I ever had to sandbox my editor in any way.

Scary.

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

#109

Post by jatins »

curuinor wrote: post #99

CodeRabbit response - https://www.coderabbit.ai/blog/our-response-to-the-january-2...

> No customer data was accessed and the vulnerability was quickly remediated within hours of disclosure

How do they know this -- Do they have any audit logs confirming this? A malicious actor could have been using this for months for all they know

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

#110

Post by gpm »

codedokode wrote: post #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 h…

> compilers (like Rust compiler) allow running arbitrary code without any warning.

It's safe to assume that the Rust compiler (like any compiler built on top of LLVM) has arbitrary code execution vulnerabilities, but as an intended feature I think this only exists in cargo, the popular/official build system, not rustc, the compiler.

Post reply on HN