A backdoor in the Ruby gem bootstrap-sass

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.

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.

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?

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.

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.

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.

It appears to evaluate ruby code provided by the client given specific strings being set in a cookie.

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