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

Hugh Sasse hgs at dmu.ac.uk
Thu Jan 18 05:20:19 EST 2007

On Wed, 17 Jan 2007, Paul Duncan wrote:

> * Hugh Sasse (hgs at dmu.ac.uk) wrote:
> > 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...
> What I'm saying is that instead of having only one door to knock on, now
> a malicious user has N doors to knock on, where N is the number of
> servers.  
> Even though having mirrors reduces the number of users that would be
> affected by a break in, it still reduces overall security because it
> increases the number of critical machines, and (by extension) the
> chances that one of them could be compromised.

Yes.  If your house only has a door it is more secure than if it
has windows as well.  
> > 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.
> RubyGems already includes cryptographic package signing (written by

Oh, I'd missed that.  It's a while since I really explored the source.

> yours truly).  There's also an entire chapter of the RubyGems manual
> dedicated to creating a certificate and signing your gems (linked

Missed that too. <blush/>
> below), so the next step is really raising developer awareness.  Here's
> the chapter on RubyGems package signing:
>   http://rubygems.org/read/chapter/21

> So the actual crypto part is already mostly complete; support for CRL
> Unfortunately, the actual crypto isn't the hard part.  
> The hard part is getting developers to adopt it.  I feel like the
> documentation is adequate, and I also posted an entry on my web site
> that has a relatively automagic gem signing blurb that can be dropped
> into a Rakefile or Gem specification.  Here it is:
>   http://pablotron.org/?cid=1510
>   (Ignore the first paragraph about the Rake patch and skip to the later
>   bit about gem signing).

OK, I'll have a look at that
> Another "hard" aspect is trust (I alluded to this in the paragraph you
> quoted above).  Specifically, how can a user be sure a particular
> certificate (or public key) is associated with the author of a given
> gem?  

Yes, this is very difficult to do, and the 1/convenience applies too.
(There are opposing forces here: we need more gems, but we need to 
make the process (more secure == less convenient).)
        [lots of well informed cryptography stuff trimmed. Thank you.]
> Obviously this is more work than most gem authors should be expected to
> do, which is why it'd be nice to have the aforementioned trust mechanism
> in place.  Even something as simple as a button to upload your signing
> key(s) to RubyForge and an ominous-sounding warning from RubyGems when
> installing unsigned gems would be better what we've got now, which is
> nothing.
> > Is there any merit in this suggestion, below?
> No.  It has several problems:
> * It doesn't actually say whether a particular gem is legitimate; it
>   says that the gem is the same as it is on the other servers.  A
>   malicious user that broke in to a server would almost certainly

I was thinking of the check being done by the client...

>   disable this check immediately.  And it doesn't address malicious gems
>   that are uploaded direcly to the master RubyForge server.

There would be no master.  It would be majority logic.

> * It has a time dependency; there's no way for any of the mirrors to
>   actually verify the digest of a particular package until other mirror
>   servers have the package, and each of them have the same problem as
>   well.

That's pretty difficult to solve. I agree.  Even if the client does
the checking, one would need some way to stop the servers accepting
any old junk.

> * It requires both network access and knowledge of several gem mirrors
>   on the client-side in order to "verify" a gem.

yes, which completely ruins offline use. Damn! I concede defeat :-)
> > <suggestion>
> >   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.
> SSL interpolates the output of multiple hash algorithms in several
> places.

Thanks. I was unfamiliar with the internals. 
> >   To plant a fake gem would mean breaking into a majority of the hash
> >   servers, rather than just one machine
> Or subverting DNS on the client side and redirecting requests for known
> gem repositories to a site the attacker controls.

Like I said, it's always more subtle! :-)
> >   It would be somewhat less prone to network/host outages iff there are
> >   >3 servers
> > 
> > Minuses:
> >   It's still pretty weak.
> Agreed (see my notes above).
> > 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,
> Agreed on the sooner part, for the reasons mentioned above and a couple
> more that I've omitted for the sake of brevity.
> (Yes, that's right; I actually left a bunch of stuff out of this
> message).

        [lots more good crypto stuff trimmed]

        Thank you,

More information about the Rubygems-developers mailing list