search

rubygems-trust / rubygems.org

The Ruby community's gem hosting service.
https://rubygems.org
MIT License
16 stars 2 forks source link

List of realistic attack scenarios (to aid the discussion) #7

Closed m-o-e closed 9 years ago

m-o-e commented 11 years ago

A few attack scenarios that any proposed scheme will have to deal with.

It would be nice if each proposal could add a short paragraph to explain how the scheme behaves in each scenario.

Please add corrections/additions to the scenarios in the comments.

Scenario 1: rubygems.org compromised, Gem modified

Rubygems.org is hacked. Attacker modifies rails-3.0.0.gem on-disk. When and how is it detected, by whom?

Scenario 2: Network MITM

Your network is untrusted. The attacker can direct your DNS lookups and connections anywhere.

You still want to install rails-3.0.0.gem with confidence that it originated from 37signals (or abort if that's not possible).

How is this ensured?

Scenario 3: 37signals signing key and credentials are stolen

The attacker can now sign and push gems as 37signals. They must stop it (revoke key?): How?

Scenario 4: Denial of Service

Rubygems.org is down. People can still get code manually from repositories, or download directly some gems stored somewhere, but how can they do that safely?

Geal commented 11 years ago

Scenario 4: Denial of Service

Rubygems.org is down. People can still get code manually from repositories, or download directly some gems stored somewhere, but how could they do that safely?

postmodern commented 11 years ago

A small variation on Scenarios 1 and 2. An attacker could compromise a gem and merely remove the signature data. Any signing solution would need to warn the user if a signature is missing, or a previously installed signed-gem is updated with an unsigned version.

Geal commented 11 years ago

I'll point out something in the Scenario 2: information leaks. Even if someone is not tampering with the packets, knowing which gems someone is downloading can give useful indications like "Company X is using an old and vulnerable gem". This can be fixed with SSL for most cases, but can be disastrous in the case of a rubygems.org compromise.

nyarly commented 11 years ago

In the case of CA: what happens if a ruby distributor (Centos, say) is hacked and changes the CA key list? When would we find out? Also, recall Debian's track record of deploying an unmodified version of rubygems, and wonder if they wouldn't set up their own CA.