6 ms·
From the CEO's response: > On January 24, 2025, security researchers from Kudelski Security disclosed a vulnerability to us through our Vulnerability Disclosur
by robomc 1y ago
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?
- deleted 1y ago[deleted]
- jdlshore 1y agoNot sure why it seems like a lie. Oversights like this happen all the time.
- wheelerwj 1y ago100%. Sounds like a very common oversight at many companies.
- cube00 1y agoIt seems like a lie because they tried to hide this incident by deflecting to a PR fluff post first [1] They only published a proper [2] disclosure post later once their hand was forced after the researcher's post hit the HN front page. [1]: https://news.ycombinator.com/item?id=44954242 https://news.ycombinator.com/item?id=44954242 [2]: I use that term loosely as it seems to be AI written slop.
- sophacles 1y ago> Why would one task run in a drastically different architectural situation Someone made a mistake. These things happen. > and it happen to be the one exploited? Why would the vulnerable service be the service that is exploited? It seems to me that's a far more likely scenario than the non-vulnerable service being exploited... no?
- bigiain 1y ago> > Why would one task run in a drastically different architectural situation > Someone made a mistake. These things happen. Some company didn't have appropriate processes in place. For ISO27001 certification you at least need to pay lip service to having documents and policies about how you deploy secure platforms. (As annoying as ISO certification is, it does at least try to ensure you have thought about andedocumented stuff like this.)
- sophacles 1y agoAh yes processes.... things done by humans. When stuff is done by humans, mistakes happen - no matter what the process is. Go do a search for the phrase "wondering how this could happen" and find millions of news articles about mistakes happening despite processes being in place!
- Romario77 1y agobecause 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.
- robomc 1y ago> because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did. 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.
- KingOfCoders 1y agoI've read it differently, they chose Rubocop not because it worked, but because it allows to execute Ruby code.
- KingOfCoders 1y agoYes, all the tools are fine and secure and sandoxed, just this one tool that was kind of randomly chosen by the security researcher because it is a tool that can execute Ruby code inside the environment - one could argue an especially dangerous tool to run - was not safe.