Strong_password Rubygem hijacked
withatwist.dev
Strong_password Rubygem hijacked
1–10 of 133 posts
Re: Strong_password Rubygem hijacked
#2It seems to me like the only way to really provide any sense of security is to force gems uploaded to RubyGems to be signed. There is some discussion here (https://github.com/rubygems/guides/pull/70) about why the Rubygems PGP CA isn't really worth using in its current state. As we've seen with Javascript dependencies, we can only put off dealing with this problem for so long.
Re: Strong_password Rubygem hijacked
#3This is a gem that checks the strength of a user-submitted password. It has a large number of downloads (37,000 on the legitimate 0.0.6 version). It looks like it's made to be integrated on webservers.
The modified gem downloaded and executed code stored in a editable Pastebin, meaning that the code could have changed at any time. Presumably, the malicious code would activate just by browsing any page on the affected site. One version of the Pastebin code would execute any code embedded in a magic cookie sent by a client. Plus, it would ping the attacker's server to let them know your webserver was infected.
Nasty, nasty stuff.
Re: Strong_password Rubygem hijacked
#4In light of vulnerabilities like these, I’m glad there are developers that spend time to make their apps more secure. Thus, making us all aware that issues like these are out there. Security is almost always just put off in exchange for features and security is most of the time taken for granted. It’s about time that we start taking it seriously.
Kudos to you!
Re: Strong_password Rubygem hijacked
#5It seems to me like the only way to really provide any sense of security is to force gems uploaded to RubyGems to be signed. There is some discussion here ( https://github.com/rubygems/guides/pull/70 ) about why the Rubygems PGP CA isn't really worth using in its current state. As we've seen with Javascript dependencies, we can only put off dealing with this problem for so long.
Requiring signatures moves all responsibility to the maintainers. I've seen projects upload their signing private keys to git, saying that it's fine because they are passphrase protected.
Sure, as 2FA, signatures help with the problem that some people use weak passwords or share their passwords. But IMO it would be better to restrict upload rights to the top 100 maintainers and give them hsms they use to authenticate those uploads. Anyone wanting to upload would have to ask one of the maintainers to sponsor them. This would reduce the number of people you have to trust when building anything from the package repository.
Re: Strong_password Rubygem hijacked
#6The unanswered question is still how this `kickball` account gained control of the gem.
> The gem seems to have been pulled out from under me… When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019.
The way I see it, there are a few options:
1. The rubygem was transferred by ruby staff to this account.
2. The maintainer's account was hijacked and then it was transferred, and could even still be compromised.
3. There is some issue or attack vector with the rubygem system that allowed the attacker to gain control.
Any guesses?
Re: Strong_password Rubygem hijacked
#7It seems to me like the only way to really provide any sense of security is to force gems uploaded to RubyGems to be signed. There is some discussion here ( https://github.com/rubygems/guides/pull/70 ) about why the Rubygems PGP CA isn't really worth using in its current state. As we've seen with Javascript dependencies, we can only put off dealing with this problem for so long.
Another solution would be changing the ecosystem to no longer be reliant on so many third party dependencies.
For instance if I am using Java and I build my web app with only Spring Framework, I can have a lot more confidence that one of my JARs hasn’t been backdoored than I can in an ecosystem where it’s regularly the practice to pull 100s of dependencies from different individual FOSS developers, where it’s difficult to audit the process that each library author is using to secure their package manager upload credentials.
I am not sure signatures are that useful since without a centralized authority to issue the certificates and securely verify author identities, we are just back to a trust-on-first-use policy for the signatures, and people will just end up setting their CI servers to always trust new signatures since they won’t want to deal with what happens when authors change their certificate from version to version (which will surely happen).
Re: Strong_password Rubygem hijacked
#8It seems to me like the only way to really provide any sense of security is to force gems uploaded to RubyGems to be signed. There is some discussion here ( https://github.com/rubygems/guides/pull/70 ) about why the Rubygems PGP CA isn't really worth using in its current state. As we've seen with Javascript dependencies, we can only put off dealing with this problem for so long.
Another solution would be changing the ecosystem to no longer be reliant on so many third party dependencies. For instance if I am using Java and I build my web app with only Spring Framework, I can have a lot more confidence that one of my JARs hasn’t been backdoored than I can in an ecosystem where it’s regularly the practice to pull 100s of dependencies from different individual FOSS developers, where it’s difficu…
Sure, obviously reinventing as many wheels as possible will minimize your exposure to third-party malfeasance.
As in all forms of engineering there are, of course, no absolutes, only trade-offs to be made.
The more wheels you reinvent, the slower your velocity for solving the core business problems that pay your bills. Moving too slowly can be fatal to the business. It’s a tricky balance. Signing isn’t perfect, but it can improve some aspects of some balances people strike.
Re: Strong_password Rubygem hijacked
#9We need a sort of capability and permission method for libraries.
For example a "strong_password" library should only by given "CPU compute" permissions, no I/O.
But even with this, the problem will be like we see on phone, popular libraries will require all the permissions.
You'll want to install React, and React + it's 100 dependencies will request everything.
Re: Strong_password Rubygem hijacked
#10The unanswered question is still how this `kickball` account gained control of the gem. > The gem seems to have been pulled out from under me… When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019. The way I see it, there are a few options: 1. The rubygem was transferred by ruby staff to this account. 2. The maintainer's account was hijacked and then it was transfe…
Yes. I think that we need to see a full security report from rubygems.org on this. This could be bigger than just the one package.