On Wed, 17 Jan 2007, Paul Duncan wrote:
> * Hugh Sasse ([EMAIL PROTECTED]) 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
Thanks
>
> 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,
Hugh
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
