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

121–130 of 244 posts

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

#121

Post by gpm »

shakna wrote: post #117
gpm wrote: post #110

Earlier quoted context omitted.

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

Any language that supports constexpr, like Rust's const fn [0], can execute arbitrary code at compile time. [0] https://github.com/rust-lang/rust/issues/57563

Rust's const fns run in a restricted interpreter that does not allow for things like non-determinism, syscalls, unsound behavior, etc. They can neither read from nor write to "the environment" in any meaningful way. They don't even expose things like the host's pointer-size to the code being run.

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

#122

Post by socalgal2 »

I've ranted about this before and been downvoted, ignored as "not an issue" but, IMO, Github is majorly to blame for this. They under-invested in their permission system so 3rd party apps are effectively encouraged to ask for "root" permissions.

Effectively, many (most?) 3rd party github integrations basically ask you to type in your github ID. Then they use the github API and ask for maximal permissions. This lets them make it easy for you to use their services because they can do all the rest of the setup for you. But, NO ONE SHOULD EVER GIVE THIS KIND OF PERMISSION.

Any 3rd party service that said "give us root to your servers" would be laughed out of the market. But, that's what github has encouraged because their default workflow leaves it up to the developer to do the right thing.

Instead, github's auth UX should (1) require you to choose repos (2) not allow picking "all repos" (3) require to you select each and every permission (4) not have an option for "all permissions".

As an analogy (though poor). iOS and MacOS don't say "this app wants all these permissions, yes/no" (android used to do this). Instead, they ask one at a time (camera? mic? photos? network?) etc... I'm not suggesting that github ask one at a time. I am suggesting that github provide a default UI that lists all the permissions, per repo, and has no way to auto-populate it so the user is required to choose.

Further, I would argue that github should show the integrations and permissions for any repo. The hope being if I see "lib X uses integration Y with write permission" then I know lib X is not trustworthy because it's open to supply chain attacks (more than lib Z which has no write integrations)

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

#123

Post by oblio »

jatins wrote: post #109
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

> How do they know this

They know because it would affect their fundraising, so obviously customer data wasn't affected.

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

#124

Post by marksomnian »

curuinor wrote: post #99

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

If I were a CodeRabbit customer, I'd still be pretty concerned after reading that.

How can CodeRabbit be certain that the GitHub App key was not exfiltrated and used to sign malicious tokens for customer repos (or even used for that in-situ)? I'm not sure if GitHub supports restricting the source IPs of API requests, but if it does, it'd be a trivial mitigation - and one that is absent from the blog post.

The claim that "no malicious activity occurred" implies that they audited the activities of every repo that used Rubocop (or any other potential unsandboxed tool) from the point that support was added for it until the point that the vulnerability was fixed. That's a big claim.

And why only publish this now, when the Kudelski article makes it to the top of HN, over six months after it was disclosed to them?

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

#126

Post by viraptor »

vadepaysa wrote: post #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.

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?

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

#128

Post by athrowaway3z »

gpm wrote: post #121
shakna wrote: post #117

Earlier quoted context omitted.

Any language that supports constexpr, like Rust's const fn [0], can execute arbitrary code at compile time. [0] https://github.com/rust-lang/rust/issues/57563

Rust's const fns run in a restricted interpreter that does not allow for things like non-determinism, syscalls, unsound behavior, etc. They can neither read from nor write to "the environment" in any meaningful way. They don't even expose things like the host's pointer-size to the code being run.

That's all interesting about const fns, but AFAIK any dependency can add a build.rs that executes anything - and is usually automatically executed by the language server doing a build on Cargo.toml file change.

Not a Rust-only problem, but one that people should be aware of in general.

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

#129

Post by mkeeter »

curuinor wrote: post #114
vadepaysa wrote: post #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.

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

The LLM tics are strong in this writeup:

"No manual overrides, no exceptions."

"Our VDP isn't just a bug bounty—it's a security partnership"

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

#130

Post by robomc »

From the CEO's response:

> On January 24, 2025, security researchers from Kudelski Security disclosed a vulnerability to us through our Vulnerability Disclosure Program (VDP). The researchers identified that Rubocop, one of our tools, was running outside our secure sandbox environment—a configuration that deviated from our standard security protocols.

Honestly, that last part sounds like a lie. Why would one task run in a drastically different architectural situation, and it happen to be the one exploited?

Post reply on HN