Security flaw caused by RC sigs [was: Release policy question]

On Thu, Feb 02, 2006 at 12:25:35PM -0600, kfogel@collab.net wrote:
> Christian Stork <cstork@ics.uci.edu> writes:
> > Hmm, then you guys might have a problem:

> > - svn x.y.0rc1 was signed by all relevant people but not released due to
> > a security flaw discovered in the last minute.
> > - svn x.y.0 released without security flaw.

> > Evil Hacker can now reuse the x.y.0rc1 sigs to make Good Company believe
> > it installed svn x.y.0 even though they installed the flawed x.y.0rc1
> > but they feel secure since they checked all relevant sigs.

> > This would be a sort of replay attack, I guess.

> This is unrelated to our numbering strategy.

Sorry, I should have changed the subject earlier.

> If release X is blessed by sufficient signers, and then later
> discovered to have a security flaw, then those who installed release X
> need to upgrade to a new, different release with its own sigs. That's
> true no matter what the names of the releases are.

The sigs should clearly identify what they mean. Maybe you
misunderstood my argument. See below.

> I don't understand exactly what Evil Hacker would do to make Good
> Company believe that the x.y.0-rc1 sigs apply to x.y.0. The two
> tarballs are different, so the sigs will be different.

Evil Hacker doesn't! She installs x.y.0-rc1 under the name x.y.0 and
gives Good Company the sigs of the RC. Then Good Company verifies the
sigs using the public keys of some committers which it received at some
key signing party.

Now you might say that Good Company should also check the publicly
available MD5 sum of the finally released tarball. Well, the problem is
that this MD5 is not signed (iiuc) and is communicated over insecure
channels. For example, Evil Hacker could have a simple filter in the
company firewall that does nothing else but replace the RC's MD5 digest
with the release's MD5 digest. Point being, this information can't be
trusted.

Of course, the subversion project could take the position that it's good
enough the allow this attack to happen for several release candidates,
but, thinking abou it, a little change in the release process could get
rid of this kind of attack.

1. RM sends out RCs
2. Committers test and approve or disapprove (go back to 1.) until
   there's an RC that has enough approvals (no sigs required yet if you
   trust email somewhat!)
3. The moment that RC is blessed, the RM and Committers sign strings like
   this

    "subversion-x.y.z.tar.gz <MD5-digest-of-subversion-x.y.z.tar.gz>"

4. From that point on (ie as soon as there exists one relevant sig of
   that form) the x.y.z version is used up.

I hope that's clearer.

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org