A backdoor in the Ruby gem bootstrap-sass(lwn.net)
lwn.net
A backdoor in the Ruby gem bootstrap-sass
https://lwn.net/SubscriberLink/785386/7792816b5e552e7e/
32 comments
This is a bit like saying we left the safe open and nothing was stolen so its not that big of a security problem. The specifics of the exploit is besides the point as it could be anything.
This is an indictment of the designers of wild lands systems like ruby Gems and npm and a culture of pulling in hundreds of dependencies that simply cannot be verified by end users.
It's one thing if this was just for developers who made a conscious decision to use a gem or npm package, but the whole system is carried on to end users who are expected to have a build environment and pull in hundreds of unknown gems and packages which in turn pull in their own dependencies simply to deploy.
This is bad engineering and design, it not only dramatically increases the complexity of deployment and wastes millions of man hours in debugging, versioning and build issues but leaves end users exposed to security issues.
This is an indictment of the designers of wild lands systems like ruby Gems and npm and a culture of pulling in hundreds of dependencies that simply cannot be verified by end users.
It's one thing if this was just for developers who made a conscious decision to use a gem or npm package, but the whole system is carried on to end users who are expected to have a build environment and pull in hundreds of unknown gems and packages which in turn pull in their own dependencies simply to deploy.
This is bad engineering and design, it not only dramatically increases the complexity of deployment and wastes millions of man hours in debugging, versioning and build issues but leaves end users exposed to security issues.
I agree with you, but I do think the ease with which dependencies are managed in eco-systems like Ruby and JS is quite valuable. As most security-related things it's a cost/benefit analysis, and the benefit of the current systems are very high.
I do wish we'd move toward more of a system of forced MFA, GPG signed binaries, and a lot more conservatism on the part of developers before pulling in other gems. I don't think it's realistic to abandon it.
I do wish we'd move toward more of a system of forced MFA, GPG signed binaries, and a lot more conservatism on the part of developers before pulling in other gems. I don't think it's realistic to abandon it.
Yeah. Zero trust for all systems, including your own. You need TLS and Auth, preferably the users Auth if the app requires that.
But also, assume it will happen so use some auditing and alerting capabilities to detect.
Review the code you're trusting, or at least look at who's shipping it so you know what your trusting ( random individual / reliable group ).
Scan as many dependicies you have, so you're aware of these rather than just luckily reading it on hacker news.
All this is really just the MVP.
But also, assume it will happen so use some auditing and alerting capabilities to detect.
Review the code you're trusting, or at least look at who's shipping it so you know what your trusting ( random individual / reliable group ).
Scan as many dependicies you have, so you're aware of these rather than just luckily reading it on hacker news.
All this is really just the MVP.
Glad to see the ruby community handled this quickly and professionally. Proud rubyist here.
Far cry from the way a recent npm vuln was handled.
Far cry from the way a recent npm vuln was handled.
Are you referencing the ESLint backdoor? From my recollection, the two incidents seem really similar. Both were noticed and unpublished quickly. Both could have been prevented by 2FA. Can you elaborate on why you think this incident was handled better?
For some reason, a subset of Rails community feels compelled to boost it by knocking whatever is more popular, e.g. Java in the old days, JavaScript these days. Rails is fine, but that aspect of the community is unnecessary and immature.
It's not fair characterize a whole community by the actions of individuals; it's just throwing around more mud.
Aside from the root comment, there is no evidence here to support the broad strokes you're making.
Aside from the root comment, there is no evidence here to support the broad strokes you're making.
I specified subset, and it's from my experiences over the years.
Yeah if you're going to sling shit like this, link to your sources. I've handled incidents involving both ecosystems over the past year and they're pretty comparable.
NPM also bought a security company (https://blog.npmjs.org/post/172793182214/npm-acquires-lift-s...) and integrated NSP directly into NPM in the form of `npm audit`.
Ruby/Gems has `bundler-audit`, which is equally good, but a separate project with a looser integration.
NPM also bought a security company (https://blog.npmjs.org/post/172793182214/npm-acquires-lift-s...) and integrated NSP directly into NPM in the form of `npm audit`.
Ruby/Gems has `bundler-audit`, which is equally good, but a separate project with a looser integration.
To all replies of this comment - it came off wrong. I didn't mean to "sling shit".
I was referring to the 'event-stream' incident in which the package maintainer unknowingly passed it off to a new malicious maintainer (he has 100s modules). The farcry between the two was that the original maintainer basically wiped his hands clean from incident, whereas in this _specific_ scenario the maintainers of 'bootstrap-sass' offered suggestions on how to improve the security and prevent similar events in the future. I was impressed by the prompt and professional response by the maintainers, that's all.
That being said - I generalized my comment too much, and I agree with zer01 that npm and bundler communities are very comparable and both do a great job.
I was referring to the 'event-stream' incident in which the package maintainer unknowingly passed it off to a new malicious maintainer (he has 100s modules). The farcry between the two was that the original maintainer basically wiped his hands clean from incident, whereas in this _specific_ scenario the maintainers of 'bootstrap-sass' offered suggestions on how to improve the security and prevent similar events in the future. I was impressed by the prompt and professional response by the maintainers, that's all.
That being said - I generalized my comment too much, and I agree with zer01 that npm and bundler communities are very comparable and both do a great job.
What I was curious about was why it targeted a fairly old and quite specific version of the gem. Made me think they had a specific target in mind.
Also, pretty impressive it was found so quickly.
Also, pretty impressive it was found so quickly.
I posted some ideas on how to reduce the risk of this kind of problem in the future. See:
https://dwheeler.com/essays/bootstrap-sass-subversion.html
A few more of these and we'll all ditch package managers in favor of plain git repos. Commit SHAs inherently guarantee content integrity.
Can you elaborate on how you see this as an integrity problem? A new malicious version was released; at no point did the attackers represent their new release as the same code as the previous release.
When you "git all the things", upgrading a dependency can equal a `git diff`. Upgrades become reviewable.
I envision a future where organisations routinely review upgrades.
I envision a future where organisations routinely review upgrades.
Next, imagine a bad library hijacks all other libraries on dev machine and compromises them too. A true pandemic warm begins. Will happen eventually to gems or npm.
Can someone explain what the backdoor could do? It's exposing some session token that someone could then use to login an account on some website that used this gem?
Everything in the first line is a diversion to make the code look complicated but realistic. The eval is what the backdoor does, which means it looks at a cookie with some basic encoding, and runs it as ruby code. There’s no authentication or anything here, the backdoor will work for anyone who cares to set that cookie.
It appears to evaluate ruby code provided by the client given specific strings being set in a cookie.
It runs arbitrary ruby code supplied in the form of a cookie.
This means the backdoor is fully generic and nobody can describe the damage, if any, that has been done.
The only saving grace is the code will run with the privileges of the ruby interpreter, constrained to the process environment of same.
This means the backdoor is fully generic and nobody can describe the damage, if any, that has been done.
The only saving grace is the code will run with the privileges of the ruby interpreter, constrained to the process environment of same.
This is at least a week old news and was promptly fixed.
> In the grand scheme of things, this backdoor likely has a fairly low impact. As noted, the backdoor was found and fixed quickly but, for a little while, it did have the potential to wreak havoc on affected sites. It is a popular gem, but the version that was backdoored was not from the current 3.4.x branch; 3.2.0.2, which was the last good version before the compromise, was released in September 2014.
Always a good reminder tho to use a defense-in-depth strategy. Containerize your applications and keep the image as lean as possibly so the attacker's capabilities are minimized.