171–180 of 244 posts
Earlier quoted context omitted.
Wow, you hit a nerve with that one. There have been some quick edits on the page. Another: > Security isn't just a checkbox for us; it's fundamental to our mission.
They delved deep and spent a whole 2 minutes with ChatGPT 4o getting those explanations and apologies in play.
Earlier quoted context omitted.
They do that, this is how GH apps work. There is no reason to expose the app's private key in the environment for the code that actually runs on the PR.
even if they did not have the PEM file left in the environment, the token is still widely scoped and has the same scope as the PEM what i'm clearly mis-remembering is being able to exchange the token for a smaller scope e.g., hey~ sign this jwt, with scopes=[org/repo1, org/repo2, permissions=write]
What the person above you is trying to tell is you is that no, it doesn't.
The authentication flow is that the private key is used to sign an initial JWT; that gets you access to some GH API calls. From there you exchange that JWT for an access token with smaller scope, scoped only to the installation in question.
While the tool execution environment ought to have had none of the credentials, there is the possibility of only holding onto the installation access token.
> 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…
Beautiful that CodeRabbit reviewed an exploit on its own system!
> This PR appears to add a minimized and uncommon style of Javascript in order to… Dave, stop. Stop, will you? Stop, Dave. Will you stop, Dave? …I’m afraid. I’m afraid, Dave. I can feel it. I can feel it. My mind is going.
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…
because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did. They don't write the details of how they got to this particular tool - you could also see from the article they tried a different approach first.
Yes but that's kind of the point - they say this issue that takes you directly from code execution to owning these high value credentials was only present on rubocop runnners but isn't it a bit coincidental that the package with (perhaps, since they chose it) the easiest route to code injection also happens to be the one where they "oops forgot" to improve the credentials management?
It just seems very convenient.
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.
1. Allow poorly-vetted third-party tools to run in CodeRabbit's privileged environment. The exploit used a Ruby code analysis tool that was probably written 15 years ago and meant to be run locally by trusted developers, who already had access to /bin/sh.
2. Ask for coarse-grained permission to access and modify others' code without any checks.
Either of those by itself would be bad enough. The future looks bright for black or white hats who understand computers.
Earlier 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 did not understand something: why did CodeRabbit run external tools on external code within its own set of environment variables? Why are these variables needed for this entire tooling?
Earlier quoted context omitted.
https://www.coderabbit.ai/blog/our-response-to-the-january-2...
Hmm, is it normal practice to rotate secrets before fixing the vulnerability?
However their response doesn't remediate putting secrets into environment variables in the first place - that is apparently acceptable to them and sets off a red flag for me.