7 ms·

Making popular Ruby packages more secure

189 points by tomstuart 4y ago

ufuk 4y ago
This is a great first step to making dependencies more secure in the Ruby ecosystem. Congrats to the whole team for getting this done!
- tessierashpool 4y ago
  yes indeed. hats off to the people working hard to make things better for everyone in Ruby.
- Gigachad 4y ago
  TFA truly was a blessing for security. Finally _something_ that can just be blindly mandated and actually works wonders. User training was not getting anywhere.
codebeaker 4y ago
As part of a team of maintainers of a popular (declining) gem, shame they don't make a mention of the extremely valid "gem is owned by a team, and anyone may push" model. I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar.
- eropple 4y ago
  I'm having trouble parsing your post. You can add multiple owners to a gem. You can also disable 2FA for API access on a per-account basis (though it isn't recommended) for a CI runner--which, tbh, is how a popular gem should be being published. What's the objection here?
- msbarnett 4y ago
  Gems can have multiple accounts able to push, and MFA tokens are per-account, not per-gem. So what's the issue exactly?
  - jacques_chester 4y ago
    In fact, you can now scope API tokens per-gem as well: https://github.com/rubygems/rubygems.org/pull/2944 https://github.com/rubygems/rubygems.org/pull/2944
  - tessierashpool 4y ago
    seems like the post you're replying to had already answered your question, in its second sentence: > I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar.
    - msbarnett 4y ago
      Still not following. "> I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar." Emphasis mine. How does "the extremely valid "gem is owned by a team, and anyone may push" model" impact this in any way? Why would the MFA tokens need to be shared via 1Password if they are specific to an individual account? Unless you're sharing the username/password for a master account between everyone with push access to the gem (which, I checked, Capistrano thankfully doesn't appear to be doing), there's no reason whatsover to share the MFA token, so it could happily exist on a separate device. And if you are sharing one username/password between everybody – don't do that. You don't need to do that to accomplish "the extremely valid "gem is owned by a team, and anyone may push" model". That's just a really stupid way to do anything. GP seems to be thinking that everyone with push rights needs to share the same token, but that's simply incorrect.
- kyrofa 4y ago
  As others have mentioned, such gems should have shared maintainership across multiple accounts (each with their own creds and MFA) as opposed to shared creds and MFA.
mhoad 4y ago
Throwing the black hat on for a moment surely I would just move towards the subdependencies of these popular gems (which realistically is where you would be targeting anyways I imagine) and can fairly reliably expect that my malicious changes get picked up upstream in due course. Am I missing something here?
- joevandyk 4y ago
  Those dependencies will be downloaded more often than the “popular” gems, so they will be affected by the same policies.
  - mhoad 4y ago
    Cool that’s what I wanted to clarify. Thank you.
  - injidup 4y ago
    They will be more popular!
- colechristensen 4y ago
  I see this kind of comment often, somebody implements a solid security improvement measure and a popular response is "what about x!?" No, enabling MFA for the most popular packages won't end all security, but also your strategy of targeting subdependencies isn't very good, every dependency of a popular project will be more popular than its dependent parent.
- Gigachad 4y ago
  I'd imagine this would end up being rolled out to almost all users eventually. Getting the top 100 done is just the warm up.
- orblivion 4y ago
  I don't know the Ruby ecosystem, but do dependencies go by hashes? If so, an update to the dependency won't immediately affect the Popular Gem. Sure, the maintainer could still naively update the dependencies and pull up a bad one during an update of the Popular Gem. But that Popular Gem update would have to happen after an attack on the dependency, and before the breach was discovered (assuming it has any way of being discovered before release of the popular package).
kyrofa 4y ago
I applaud the move in the right direction, but please add support for webauthn. OTPs are really inconvenient in comparison. It looks like maybe it's been in flight for a while? https://github.com/rubygems/rubygems.org/pull/2108 https://github.com/rubygems/rubygems.org/pull/2108
- jacques_chester 4y ago
  It's on the radar. While that effort has come to a halt, some of us would like to pick it up and get it over the line at some point.
woodruffw 4y ago
Fantastic work by the RubyGems maintainers. Congratulations on the rollout, and please consider WebAuthn support in a future iteration!
jupp0r 4y ago
How about cryptographically signed packages as the next step? It boggles my mind that most popular package managers like npm, pip and cargo don't have verification of package authenticity before installing built in.
- klysm 4y ago
  I think HTTPS gets you pretty far. There are far more concerning attack vectors for those package ecosystems to me
  - loic-sharma 4y ago
    Supply chain attacks are not uncommon. Package signing can protect against those: 1. Package source hacking. Say an attacker gets access to a package source's storage and inserts malware into popular packages. Now your project contains malware. Your package manager can detect tampering if the packages are signed. 2. Dependency confusion attacks. Say my project downloads packages from the public source as well as my company's private source. An attacker realizes my company has a private package named `private-foo` and uploads a malicious package with the same name to the public source. Now my projects contains malware as it occasionally downloads the malicious package instead of my company's private package. Your package manager can detect packages from an unexpected author if they are signed. I can provide more examples if you'd like. None of these are hypothetical, all of them have happened already.
    - kayodelycaon 4y ago
      > Dependency confusion attacks Just want to point out that bundler solves this problem (and many others). It pins gem versions in Gemfile.lock and it supports explicit source locations (like git repositories) for downloading gems.
  - jacques_chester 4y ago
    HTTPS only protects the transmission from repository to user. It doesn't protect the package in the repository.
ievans 4y ago
This is great news! I like how the article cites evidence that MFA is disproportionately effective against account takeover. If the rubygems devs are looking for other highly effective wins against supply chain attacks: I think the next thing is deeper support for lockfiles. Although Ruby has Gemfile.lock, it's not a true lockfile in the same way that package managers in the javascript/go/python ecosystems are. Specifically, locking versions is optional, there's no locking by hash (Github issue: https://github.com/rubygems/rubygems/issues/3379 https://github.com/rubygems/rubygems/issues/3379), and there's no capability to lock local or source-only dependencies by hash. By comparison: go modules, pipenv, npm, yarn, nuget, composer, and gradle already support locking by hash.
- thayne 4y ago
  you can add cargo to that list as well.
captn3m0 4y ago
I really wish more package managers added support for OIDC based authentication+authorization for package publishing. PyPi has an ongoing PR for this: https://github.com/pypa/warehouse/issues/10970 https://github.com/pypa/warehouse/issues/10970 with some really great UX. You specify a repository name on GitHub and GitHub actions there get publishing rights automatically. While 2FA is good, having a purpose limited JIT token for publishing packages is what will actually reduce risk. Otherwise, as it stands - PATs leaked from one project can be used across any of your other packages on all package managers.
- woodruffw 4y ago
  Thanks for giving the OIDC work a shoutout! I'm also (biasedly) very excited about it.
madmaniak 4y ago
Does MFA exists to force people to have/carry all the time smart phones or there's a way to use it without a phone? I mean in practice for repositories like npm or rubygems?
- jen20 4y ago
  It’s around 20 lines of Python (with no third party dependencies) to write a TOTP generator, so no.
- tomstuart 4y ago
  You need somewhere to physically store a secret, plus the ability to do some computation to turn that secret into a time-based one-time code. A lot of people do use their phone, but there’s nothing to stop you using a dedicated hardware token, or conversely just your computer (e.g. 1Password [0]) if you’re comfortable with keeping all your secrets in the same place. Naturally there are security/convenience tradeoffs however you do it. The important thing is that, unlike with passwords, you never send the secret over the wire. [0] https://blog.1password.com/totp-and-1password/#totp-isnt-the-same-as-two-factor-security https://blog.1password.com/totp-and-1password/#totp-isnt-the...
capableweb 4y ago
Anyone know what happens to the people who won't activate MFA within the time-period? I'm guessing they'll be unable to publish, but still be able to login to their account to setup MFA, even after MFA started to become mandatory?
- tomstuart 4y ago
  That’s correct. If you’re a maintainer of a very popular gem, as of 15th August you’ll no longer be able to e.g. `gem push` if you haven’t enabled MFA on your RubyGems account. You will of course still be able to log in and enable it. More details in the RFC: https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-rollout.md#phase-3-enforcing-mfa-on-most-downloaded-gems-est-julyaug-2022 https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-r...
  - capableweb 4y ago
    Thanks a lot for the quick clarification :)

189 points by tomstuart 4y ago

ufuk 4y ago

This is a great first step to making dependencies more secure in the Ruby ecosystem. Congrats to the whole team for getting this done!

tessierashpool 4y ago
yes indeed. hats off to the people working hard to make things better for everyone in Ruby.
Gigachad 4y ago
TFA truly was a blessing for security. Finally _something_ that can just be blindly mandated and actually works wonders. User training was not getting anywhere.

codebeaker 4y ago

As part of a team of maintainers of a popular (declining) gem, shame they don't make a mention of the extremely valid "gem is owned by a team, and anyone may push" model. I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar.

eropple 4y ago
I'm having trouble parsing your post. You can add multiple owners to a gem. You can also disable 2FA for API access on a per-account basis (though it isn't recommended) for a CI runner--which, tbh, is how a popular gem should be being published. What's the objection here?
msbarnett 4y ago
Gems can have multiple accounts able to push, and MFA tokens are per-account, not per-gem. So what's the issue exactly?
- jacques_chester 4y ago
  In fact, you can now scope API tokens per-gem as well: https://github.com/rubygems/rubygems.org/pull/2944 https://github.com/rubygems/rubygems.org/pull/2944
- tessierashpool 4y ago
  seems like the post you're replying to had already answered your question, in its second sentence: > I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar.
  - msbarnett 4y ago
    Still not following. "> I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar." Emphasis mine. How does "the extremely valid "gem is owned by a team, and anyone may push" model" impact this in any way? Why would the MFA tokens need to be shared via 1Password if they are specific to an individual account? Unless you're sharing the username/password for a master account between everyone with push access to the gem (which, I checked, Capistrano thankfully doesn't appear to be doing), there's no reason whatsover to share the MFA token, so it could happily exist on a separate device. And if you are sharing one username/password between everybody – don't do that. You don't need to do that to accomplish "the extremely valid "gem is owned by a team, and anyone may push" model". That's just a really stupid way to do anything. GP seems to be thinking that everyone with push rights needs to share the same token, but that's simply incorrect.
kyrofa 4y ago
As others have mentioned, such gems should have shared maintainership across multiple accounts (each with their own creds and MFA) as opposed to shared creds and MFA.

mhoad 4y ago

Throwing the black hat on for a moment surely I would just move towards the subdependencies of these popular gems (which realistically is where you would be targeting anyways I imagine) and can fairly reliably expect that my malicious changes get picked up upstream in due course. Am I missing something here?

joevandyk 4y ago
Those dependencies will be downloaded more often than the “popular” gems, so they will be affected by the same policies.
- mhoad 4y ago
  Cool that’s what I wanted to clarify. Thank you.
- injidup 4y ago
  They will be more popular!
colechristensen 4y ago
I see this kind of comment often, somebody implements a solid security improvement measure and a popular response is "what about x!?" No, enabling MFA for the most popular packages won't end all security, but also your strategy of targeting subdependencies isn't very good, every dependency of a popular project will be more popular than its dependent parent.
Gigachad 4y ago
I'd imagine this would end up being rolled out to almost all users eventually. Getting the top 100 done is just the warm up.
orblivion 4y ago
I don't know the Ruby ecosystem, but do dependencies go by hashes? If so, an update to the dependency won't immediately affect the Popular Gem. Sure, the maintainer could still naively update the dependencies and pull up a bad one during an update of the Popular Gem. But that Popular Gem update would have to happen after an attack on the dependency, and before the breach was discovered (assuming it has any way of being discovered before release of the popular package).

kyrofa 4y ago

I applaud the move in the right direction, but please add support for webauthn. OTPs are really inconvenient in comparison. It looks like maybe it's been in flight for a while? https://github.com/rubygems/rubygems.org/pull/2108 https://github.com/rubygems/rubygems.org/pull/2108

jacques_chester 4y ago
It's on the radar. While that effort has come to a halt, some of us would like to pick it up and get it over the line at some point.

woodruffw 4y ago

Fantastic work by the RubyGems maintainers. Congratulations on the rollout, and please consider WebAuthn support in a future iteration!

jupp0r 4y ago

How about cryptographically signed packages as the next step? It boggles my mind that most popular package managers like npm, pip and cargo don't have verification of package authenticity before installing built in.

klysm 4y ago
I think HTTPS gets you pretty far. There are far more concerning attack vectors for those package ecosystems to me
- loic-sharma 4y ago
  Supply chain attacks are not uncommon. Package signing can protect against those: 1. Package source hacking. Say an attacker gets access to a package source's storage and inserts malware into popular packages. Now your project contains malware. Your package manager can detect tampering if the packages are signed. 2. Dependency confusion attacks. Say my project downloads packages from the public source as well as my company's private source. An attacker realizes my company has a private package named `private-foo` and uploads a malicious package with the same name to the public source. Now my projects contains malware as it occasionally downloads the malicious package instead of my company's private package. Your package manager can detect packages from an unexpected author if they are signed. I can provide more examples if you'd like. None of these are hypothetical, all of them have happened already.
  - kayodelycaon 4y ago
    > Dependency confusion attacks Just want to point out that bundler solves this problem (and many others). It pins gem versions in Gemfile.lock and it supports explicit source locations (like git repositories) for downloading gems.
- jacques_chester 4y ago
  HTTPS only protects the transmission from repository to user. It doesn't protect the package in the repository.

ievans 4y ago

This is great news! I like how the article cites evidence that MFA is disproportionately effective against account takeover. If the rubygems devs are looking for other highly effective wins against supply chain attacks: I think the next thing is deeper support for lockfiles. Although Ruby has Gemfile.lock, it's not a true lockfile in the same way that package managers in the javascript/go/python ecosystems are. Specifically, locking versions is optional, there's no locking by hash (Github issue: https://github.com/rubygems/rubygems/issues/3379 https://github.com/rubygems/rubygems/issues/3379), and there's no capability to lock local or source-only dependencies by hash. By comparison: go modules, pipenv, npm, yarn, nuget, composer, and gradle already support locking by hash.

thayne 4y ago
you can add cargo to that list as well.

captn3m0 4y ago

I really wish more package managers added support for OIDC based authentication+authorization for package publishing. PyPi has an ongoing PR for this: https://github.com/pypa/warehouse/issues/10970 https://github.com/pypa/warehouse/issues/10970 with some really great UX. You specify a repository name on GitHub and GitHub actions there get publishing rights automatically. While 2FA is good, having a purpose limited JIT token for publishing packages is what will actually reduce risk. Otherwise, as it stands - PATs leaked from one project can be used across any of your other packages on all package managers.

woodruffw 4y ago
Thanks for giving the OIDC work a shoutout! I'm also (biasedly) very excited about it.

madmaniak 4y ago

Does MFA exists to force people to have/carry all the time smart phones or there's a way to use it without a phone? I mean in practice for repositories like npm or rubygems?

jen20 4y ago
It’s around 20 lines of Python (with no third party dependencies) to write a TOTP generator, so no.
tomstuart 4y ago
You need somewhere to physically store a secret, plus the ability to do some computation to turn that secret into a time-based one-time code. A lot of people do use their phone, but there’s nothing to stop you using a dedicated hardware token, or conversely just your computer (e.g. 1Password [0]) if you’re comfortable with keeping all your secrets in the same place. Naturally there are security/convenience tradeoffs however you do it. The important thing is that, unlike with passwords, you never send the secret over the wire. [0] https://blog.1password.com/totp-and-1password/#totp-isnt-the-same-as-two-factor-security https://blog.1password.com/totp-and-1password/#totp-isnt-the...

capableweb 4y ago

Anyone know what happens to the people who won't activate MFA within the time-period? I'm guessing they'll be unable to publish, but still be able to login to their account to setup MFA, even after MFA started to become mandatory?

tomstuart 4y ago
That’s correct. If you’re a maintainer of a very popular gem, as of 15th August you’ll no longer be able to e.g. `gem push` if you haven’t enabled MFA on your RubyGems account. You will of course still be able to log in and enable it. More details in the RFC: https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-rollout.md#phase-3-enforcing-mfa-on-most-downloaded-gems-est-julyaug-2022 https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-r...
- capableweb 4y ago
  Thanks a lot for the quick clarification :)