5 ms·

RubyGems.org gem replacement security vulnerability and mitigation

141 points by arthurnn 10y ago

kentt 10y ago
I appreciate the way this was disclosed, especially that the author was very clear. Often security vulnerability disclosers are hard to understand.
entitydc 10y ago
Big thanks to the authors of this post. It's written in such a way as the scope of the vulnerability is immediately clear and immediately actionable.
dcu 10y ago
I just wrote a simple script to check the gems: https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d
- seanhandley 10y ago
  This is really helpful - thanks!
- elcapitan 10y ago
  Thanks! Probably depending on version, it seems to be missing a require 'time' require 'json' in my environment.
- revorad 10y ago
  Thanks for this. So I ran this and found a bunch of unsafe gems. Do I report them to each gem author or to RubyGems security?
  - davidradcliffe 10y ago
    In this context "unsafe" only means not 100% verified.
  - dcu 10y ago
    I think we should ask the gem owner to verify that everything is ok unless there's a new version. I updated the script to report if there is a new safe version available.
- brightshiny 10y ago
  Thanks for this. I did some extra work on it (via someone else's fork) so it can run across multiple directories. I've too many projects lurking around to cd into all of them! I added some pretty colours too :) https://gist.github.com/yb66/44b97baecbeec6900e039ffb9461d31e https://gist.github.com/yb66/44b97baecbeec6900e039ffb9461d31...
click170 10y ago
I worry for all the unmaintained but still available gems.
hellbanner 10y ago
Great response. It's still sad to me in 2016 we don't have reliable build systems for otherwise such modern programming tools. I understand why.. just sad. Great job on the investigation though.
- colanderman 10y ago
  Reliable, secure package management systems have existed for a long time [1] [2] [3]. Ruby, Node, Python, et al. just choose to ignore them, just like they choose to ignore other proven development tools [4]. [1] https://debian-handbook.info/browse/stable/sect.package-authentication.html https://debian-handbook.info/browse/stable/sect.package-auth... [2] https://access.redhat.com/security/team/key/ https://access.redhat.com/security/team/key/ [3] https://wiki.archlinux.org/index.php/DeveloperWiki:Package_signing https://wiki.archlinux.org/index.php/DeveloperWiki:Package_s... [4] https://en.wikipedia.org/wiki/Make_(software) https://en.wikipedia.org/wiki/Make_(software)
  - FooBarWidget 10y ago
    Sigh, I know that it's easy to paint an outside group of programmers as incompetent fools who choose to ignore the Obvious Solutions(tm), but how many times must this be discussed before people realize that distribution package managers cannot replace the language-specific package systems? Language-specific package systems have requirements which distribution package managers like apt/dpkg, rpm/yum, pacman etc do not fulfill. Just to name a few requirements: - OS-independent. It's great that your package manager works well with your OS, but as a developer I want to target all my users, not just one OS. Nor do I want to make a bazillion packages for different OSes which takes a lot of time. I know that a lot of people have this attitude of "no, make a package for MY OS, I don't care about other OSes or how difficult it is for you", but this sort of "my way or the highway" unemphatic attitude is unhelpful. Clearly developers have chosen the highway. - Ability to release outside OS package management schedules. I don't want users to wait half a year for the next distribution release before they can use the latest version of my app/library. Yes, some of you are using rolling release distributions, but that doesn't help developers because not all users are on rolling release distributions. - Non-root installs. - Ability to install multiple versions in parallel. RPM and DPKG do it by suffixing a version number in the package name but this is kind of hacky, we need real support. I'm sure some package managers (maybe Nix? Guix?) can do the above but they came too late, there's too little momentum. So why didn't Ruby/Node/Python etc developers adapt RPM/DPKG/etc? A few reasons include: - Arcane, or complete lack of, documentation. Try to make a Debian package. It's a nightmare: the documentation is scattered all over the place, throws arcane terms at you as if you should have known them for a decade, and doesn't explain basic concepts very well. - Many OS package managers are written in C. Many Ruby/Node/Python do not know C (or know it well). - Lack of understanding of the problem domain. Here I give you some credit. When writing language-specific package managers, the authors probably did not fully understand the problem domain in the beginning. If they did, they might have looked at OS package managers more (or at least learned more lessons from them). But the aforementioned problems still stand. Don't even get me started on Make. Make has its own set of problems.
derekprior 10y ago
The manual verification steps are basically impossible for any non-trivial gem. I wonder if it would be possible to re-build (from git) the impacted gem versions and check their checksum against the downloaded version to detect differences?
seanhandley 10y ago
To save app developers manually trawling dozens of gems and duplicating work, we need to have somewhere that people can publicly disclose gems they've found to be compromised.
- davidradcliffe 10y ago
  If anyone finds compromised gems they should report them to the RubyGems.org security team immediately.
zwp 10y ago
The commit to fix this appears to be "validate Version full_name": https://github.com/rubygems/rubygems.org/commit/1067ab7e0871bf7b75832944d839c8e0495aeb92 https://github.com/rubygems/rubygems.org/commit/1067ab7e0871... Cause: a "full name" is a dash-seperated join of its components, yet those components may themselves contain dashes :(
bhaak 10y ago
The real WTF is that they only started checksumming the gems in 2015!
quakershake 10y ago
Anyone know why the date listed for a gem listed on rubygems.org wouldn't match the contents of the gem? I am guessing possible timezone differences. But some clarification would be nice. For example: Listed for bundler -v 1.11.2 - December 16, 2015 (257 KB) $ tar tvf bundler-1.11.2.gem -r--r--r-- 0 wheel wheel 2161 Dec 15 19:12 metadata.gz -r--r--r-- 0 wheel wheel 257198 Dec 15 19:12 data.tar.gz -r--r--r-- 0 wheel wheel 267 Dec 15 19:12 checksums.yaml.gz
- quakershake 10y ago
  I've also noticed that there are gems listed on rubygems.org that have dates in the past relative to the gem contents. Nevermind - its the date in the gem spec

141 points by arthurnn 10y ago

kentt 10y ago

I appreciate the way this was disclosed, especially that the author was very clear. Often security vulnerability disclosers are hard to understand.

entitydc 10y ago

Big thanks to the authors of this post. It's written in such a way as the scope of the vulnerability is immediately clear and immediately actionable.

dcu 10y ago

I just wrote a simple script to check the gems: https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d

seanhandley 10y ago
This is really helpful - thanks!
elcapitan 10y ago
Thanks! Probably depending on version, it seems to be missing a require 'time' require 'json' in my environment.
revorad 10y ago
Thanks for this. So I ran this and found a bunch of unsafe gems. Do I report them to each gem author or to RubyGems security?
- davidradcliffe 10y ago
  In this context "unsafe" only means not 100% verified.
- dcu 10y ago
  I think we should ask the gem owner to verify that everything is ok unless there's a new version. I updated the script to report if there is a new safe version available.
brightshiny 10y ago
Thanks for this. I did some extra work on it (via someone else's fork) so it can run across multiple directories. I've too many projects lurking around to cd into all of them! I added some pretty colours too :) https://gist.github.com/yb66/44b97baecbeec6900e039ffb9461d31e https://gist.github.com/yb66/44b97baecbeec6900e039ffb9461d31...

click170 10y ago

I worry for all the unmaintained but still available gems.

hellbanner 10y ago

Great response. It's still sad to me in 2016 we don't have reliable build systems for otherwise such modern programming tools. I understand why.. just sad. Great job on the investigation though.

colanderman 10y ago
Reliable, secure package management systems have existed for a long time [1] [2] [3]. Ruby, Node, Python, et al. just choose to ignore them, just like they choose to ignore other proven development tools [4]. [1] https://debian-handbook.info/browse/stable/sect.package-authentication.html https://debian-handbook.info/browse/stable/sect.package-auth... [2] https://access.redhat.com/security/team/key/ https://access.redhat.com/security/team/key/ [3] https://wiki.archlinux.org/index.php/DeveloperWiki:Package_signing https://wiki.archlinux.org/index.php/DeveloperWiki:Package_s... [4] https://en.wikipedia.org/wiki/Make_(software) https://en.wikipedia.org/wiki/Make_(software)
- FooBarWidget 10y ago
  Sigh, I know that it's easy to paint an outside group of programmers as incompetent fools who choose to ignore the Obvious Solutions(tm), but how many times must this be discussed before people realize that distribution package managers cannot replace the language-specific package systems? Language-specific package systems have requirements which distribution package managers like apt/dpkg, rpm/yum, pacman etc do not fulfill. Just to name a few requirements: - OS-independent. It's great that your package manager works well with your OS, but as a developer I want to target all my users, not just one OS. Nor do I want to make a bazillion packages for different OSes which takes a lot of time. I know that a lot of people have this attitude of "no, make a package for MY OS, I don't care about other OSes or how difficult it is for you", but this sort of "my way or the highway" unemphatic attitude is unhelpful. Clearly developers have chosen the highway. - Ability to release outside OS package management schedules. I don't want users to wait half a year for the next distribution release before they can use the latest version of my app/library. Yes, some of you are using rolling release distributions, but that doesn't help developers because not all users are on rolling release distributions. - Non-root installs. - Ability to install multiple versions in parallel. RPM and DPKG do it by suffixing a version number in the package name but this is kind of hacky, we need real support. I'm sure some package managers (maybe Nix? Guix?) can do the above but they came too late, there's too little momentum. So why didn't Ruby/Node/Python etc developers adapt RPM/DPKG/etc? A few reasons include: - Arcane, or complete lack of, documentation. Try to make a Debian package. It's a nightmare: the documentation is scattered all over the place, throws arcane terms at you as if you should have known them for a decade, and doesn't explain basic concepts very well. - Many OS package managers are written in C. Many Ruby/Node/Python do not know C (or know it well). - Lack of understanding of the problem domain. Here I give you some credit. When writing language-specific package managers, the authors probably did not fully understand the problem domain in the beginning. If they did, they might have looked at OS package managers more (or at least learned more lessons from them). But the aforementioned problems still stand. Don't even get me started on Make. Make has its own set of problems.

derekprior 10y ago

The manual verification steps are basically impossible for any non-trivial gem. I wonder if it would be possible to re-build (from git) the impacted gem versions and check their checksum against the downloaded version to detect differences?

seanhandley 10y ago

To save app developers manually trawling dozens of gems and duplicating work, we need to have somewhere that people can publicly disclose gems they've found to be compromised.

davidradcliffe 10y ago
If anyone finds compromised gems they should report them to the RubyGems.org security team immediately.

zwp 10y ago

The commit to fix this appears to be "validate Version full_name": https://github.com/rubygems/rubygems.org/commit/1067ab7e0871bf7b75832944d839c8e0495aeb92 https://github.com/rubygems/rubygems.org/commit/1067ab7e0871... Cause: a "full name" is a dash-seperated join of its components, yet those components may themselves contain dashes :(

bhaak 10y ago

The real WTF is that they only started checksumming the gems in 2015!

quakershake 10y ago

Anyone know why the date listed for a gem listed on rubygems.org wouldn't match the contents of the gem? I am guessing possible timezone differences. But some clarification would be nice. For example: Listed for bundler -v 1.11.2 - December 16, 2015 (257 KB) $ tar tvf bundler-1.11.2.gem -r--r--r-- 0 wheel wheel 2161 Dec 15 19:12 metadata.gz -r--r--r-- 0 wheel wheel 257198 Dec 15 19:12 data.tar.gz -r--r--r-- 0 wheel wheel 267 Dec 15 19:12 checksums.yaml.gz

quakershake 10y ago
I've also noticed that there are gems listed on rubygems.org that have dates in the past relative to the gem contents. Nevermind - its the date in the gem spec