[Rubygems-developers] Need to release 0.9.1 due to security exploit

Hugh Sasse hgs at dmu.ac.uk
Wed Jan 17 04:27:11 EST 2007

On Tue, 16 Jan 2007, Paul Duncan wrote:

> The _really_ bad news is this type of attack became a whole lot easier
> once RubyGems started using mirrors.  Instead of worrying about a
> malicious user breaking into one machine (rubyforge.org), we now have to
> worry about them breaking into N machines, where N is the number of
> Gem mirrors.

That's "breaking into any one of N machines" I take it?  Having to
hack more than one would make it stronger, but 1 of N weaker...

> The only way to completely eliminate this type of attack would be to
> force gem authors to sign their gems, create an author certificate
> distribution mechanism (or tie it to some sort of existing trust
> mechanism like X.509 or PGP keyservers [1]), remove all the unsigned
> gems from the Gem repositories, and (finally) enable signature checking
> by default in RubyGems. 
> Frankly, I don't see all of that (or any of it, really) happening any
> time soon.

I'd prefer to not get into all that as well.  Doing cryptography right,
keeping the keys somewhere useful but sufficiently inaccessible, coping
with the (changes in) cryptography legislation: it's all rather horrible.

Is there any merit in this suggestion, below?

SHA256 hashes of the gems are kept on at least 3 servers.  A gem is accepted
from a mirror if it's hash agrees with a majority of the responses from
those servers.

  Ruby contains the code for SHA256 in the standard library and it's better
  than md5 (harder work to fake).  Maybe both together would be stronger.
  To plant a fake gem would mean breaking into a majority of the hash
  servers, rather than just one machine

  It would be somewhat less prone to network/host outages iff there are
  >3 servers

  It's still pretty weak.

  we need some mechanism to prevent the data being replicated (falsely)
  across a majority/all the servers

  How do we keep people up to date with where the servers are, which
  can be trusted, etc, without weakening security?  "Key under the
  doormat" problem.  (security = 1/convenience)


  Could be applied to more than just the gems.

I'm sure this is really rather naive, and what I've read about NOT
implementing security systems from the ground up leads me to believe
that this idea should probably be killed sooner rather than later,
but in the hope that it is an improvement over where we are now, I
will risk my global display of ignorance....


More information about the Rubygems-developers mailing list