> 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.
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.
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.
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.
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.
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.
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.
Earlier in my career I was a Rails dev. Since it's on my Linkedin, I get PMs at least once a week about Rails gigs from companies in SF/SV. Rails isn't dead. Furthermore having had stints with Django and React, I think Rails is still by far the simplest and most pleasurable way to build webapps. Their core philosophy of maximizing developer happiness has something to do with it.
I treat bootstrap like GTK+ for the web. When I need an application, that happens to be a website, to have a consistent/nice look/feel without having to "design" it.
Rails is (and has been) a pleasure to use for fast, easy-ish development if you usually stick to the "Rails style" recommend naming schemes, etc.
If you are trying to adapt an existing project/db that uses some other style, Rails might not be the best tool to use. When you have to supply explicit table/key/route name overrides to everything, you loose a lot of the benefit of using Rails (or any other very-opinionated tool). I loved using rails for multiple projects, but it's worth making sure it's actually a good fit for the project before jumping in.
Discourse too. But frankly I wish people stop making publicly releasing software as rails app, the resource usage is just insane. I always have to upgrade my server just because of running a single rails app.
> 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.