Good thing your Gemfile.lock is checked in and gems hosted on rubygems.org are frozen / imutable
Rest-client gem is hijacked
41–50 of 113 posts
Re: Rest-client gem is hijacked
#42Earlier quoted context omitted.
Yeah this problem has been a known issue for a long time, but there really is no easy fix, and incentives are stacked against it getting resolved in any meaningful way. I did a talk for AppsecEU back in 2015 on this topic and found good material talking about it as a risk going back years before that...
I think I might start using fully isolated environments (i.e., via Vagrant/Docker/etc.) for all of my projects from now on (I already do for some).
That approach will mitigate your machine getting compromised (which is good) but it won't fix your production machines getting compromised if the gem or package gets deployed. That is usually a much worse outcome.
And even in isolated environments I find myself running code outside of the container for testing. Usually a quick script to test some package's functionality or opening a REPL to run something or running a code-generator (manage.py, artisan, etc). That's all it takes for the malware to break out of the isolation and attack your machine.
Re: Rest-client gem is hijacked
#43Ruby gem hijacking also happened to Strong_password a few weeks ago. https://news.ycombinator.com/item?id=20377136 This is major new line of attack, and web app infrastructure is critically weak to it. We rejected distro-controlled package management in favor of pip and gem and npm years ago (for good reasons), but as this sort of attack becomes much more common (which it will), we might find ourselves missing the da…
> We rejected distro-controlled package management in favor of pip and gem and npm years ago (for good reasons)
While I'm generally a fan of distribution-provided packages, they would not have helped in this case. Distributions simply lack the manpower to audit all upstream releases for these kinds of issues.
Re: Rest-client gem is hijacked
#44Is there a way to check if a gem was released by an account using MFA?
If there was a "published with mfa" flag on every gem release and it would allow a Bundler setting to block installing gems without 2FA.
Of course, this would also help attackers find targets. But maybe its worth the trade-off?
Re: Rest-client gem is hijacked
#45Earlier quoted context omitted.
Yeah this problem has been a known issue for a long time, but there really is no easy fix, and incentives are stacked against it getting resolved in any meaningful way. I did a talk for AppsecEU back in 2015 on this topic and found good material talking about it as a risk going back years before that...
> there really is no easy fix Is there any fix at all? Aside from something like multiple-account code signing/release verification I cannot think of something that couldn't be compromised in some way. At the end of the day you have to trust someone and trust that they trust someone else. The problem is you have no way of vetting the entire dependency chain. You may have reviewed gem/package A but you aren't going to…
I'd debate the relatively effective piece in light of webmin being backdoored for a year, and of course remember we're only hearing about the ones that have been found, not the ones that haven't.
There's a number of possible technical mitigations, maintaining internal package repositories, code review of key libraries, enforcing package signing and checking signatures etc but all of them increase costs and decrease development speed, so they're not adopted that heavily.
There are also possible mitigations at a legislative/policy level, but they would be so deeply unpopular that I'm sure they'd never pass muster in most countries.
Re: Rest-client gem is hijacked
#46It's worth noting that the hijacker pushed a malicious version of 1.6.x Version 1.7.0 was released to rubygems on 8th July 2014, and 2.0.0 on 2nd July 2016, so anyone who has started using rest-client or run a `bundle update` recently is unlikely to be affected. The impact could have been significantly greater had the hijacker pushed a new versions of 1.8.x or 2.x as well, so it's very fortunate the breach was spotte…
That's a good point. Could indicate a targeted attack?
That was my first thought - it would seem as though releasing on a version that old would be deliberate and why else would you do that if you weren't targeting something specific?
Re: Rest-client gem is hijacked
#47I think that rubygems should consider automatically enforcing multifactor authentication for popular gems. So any gem with more than 50,000 downloads should force to gem maintainer to have MFA set up before they can publish a new version or do anything with that gem. Because, having MFA is not about protecting gem maintainers, it's about protecting users. So, gem maintainers should not be allowed to be careless with…
It's only a matter of time before this will happen. Once any one of the big players (rubygems, npm, Maven central, PyPi) enforces 2FA, all other repos will soon have to follow suit or risk giving appearance of haphazard attitude towards user security.
2FA is generally trivial for maintainers to take into use. There is simply no excuse to not require it at this point for all new uploads. The status quo of hoping maintainers never re-use their passwords / use weak passwords / have their machines hacked is clearly not working since security incidents like this keep happening every other week with Rubygems/npm/etc.
Re: Rest-client gem is hijacked
#48Earlier quoted context omitted.
Actually publishing new versions seems like something that happens infrequently enough that it would be fine to require a manual auth to complete it. Given the potential risks it seems prudent.
I'd expect that very much depends on the software in question. As one example that I'm aware of, gvisor from Google delivers nightly builds. So they're building and pushing every single day. It'd depend on the individual software library and of course as a consumer of many libraries you generally will have limited or no visibility of the practices of all your dependencies.
I don't think nightly builds are the same thing as releases - you can have CI publish a build but to create a versioned public release it should require manual auth.
Re: Rest-client gem is hijacked
#49Ruby gem hijacking also happened to Strong_password a few weeks ago. https://news.ycombinator.com/item?id=20377136 This is major new line of attack, and web app infrastructure is critically weak to it. We rejected distro-controlled package management in favor of pip and gem and npm years ago (for good reasons), but as this sort of attack becomes much more common (which it will), we might find ourselves missing the da…
With regards to Rubygems, the challenge is likely to be where they get the resources for additional security measures.
All the major language repo's are free at point of use, and I don't get the impression the maintainers are exactly rolling in money, so it doesn't seem likely that they can easily ramp up on that front.
Re: Rest-client gem is hijacked
#50Is there a way to check if a gem was released by an account using MFA? If there was a "published with mfa" flag on every gem release and it would allow a Bundler setting to block installing gems without 2FA. Of course, this would also help attackers find targets. But maybe its worth the trade-off?
Seems like a pointless, false sense of security.
What about all the attacks where the malicious actor is someone with publish rights, like friendly package takeover? Your proposal makes that even more effective since now the attacker gets a nice "published with mfa" badge.