
RubyGems.org  gem replacement security vulnerability and mitigation - arthurnn
http://blog.rubygems.org/2016/04/06/gem-replacement-vulnerability-and-mitigation.html
======
entitydc
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.

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

------
dcu
I just wrote a simple script to check the gems:

[https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d](https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d)

~~~
revorad
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?

~~~
dcu
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.

------
zwp
The commit to fix this appears to be "validate Version full_name":

[https://github.com/rubygems/rubygems.org/commit/1067ab7e0871...](https://github.com/rubygems/rubygems.org/commit/1067ab7e0871bf7b75832944d839c8e0495aeb92)

Cause: a "full name" is a dash-seperated join of its components, yet those
components may themselves contain dashes :(

------
hellbanner
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
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-
auth...](https://debian-handbook.info/browse/stable/sect.package-
authentication.html)

[2]
[https://access.redhat.com/security/team/key/](https://access.redhat.com/security/team/key/)

[3]
[https://wiki.archlinux.org/index.php/DeveloperWiki:Package_s...](https://wiki.archlinux.org/index.php/DeveloperWiki:Package_signing)

[4]
[https://en.wikipedia.org/wiki/Make_(software)](https://en.wikipedia.org/wiki/Make_\(software\))

~~~
FooBarWidget
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.

~~~
hellbanner
Thanks for your excellent reply. Do you think support for Nix, Guix etc will
increase, or will reliable package systems only become more fragmented?

I do remember seeing a Linux variant announce they had achieved full trusted
compilation a while back (on HN), which was pleasant to see but sadly too
rare.

------
quakershake
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
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_

------
click170
I worry for all the unmaintained but still available gems.

------
derekprior
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
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
If anyone finds compromised gems they should report them to the RubyGems.org
security team immediately.

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

