Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Aug 31, Sergey A. Lipnevich [sergey AT optimaltec.com] wrote:
> The beauty of hashes is that they don't need any extra support in addition 
> to
> what's in sorcery now. Sign the grimoire tarball with a GPG signature and 
> it's
> good to go. Nothing needs to be revoked if the malicious hash code was 
> entered.
> Replace bad hash value, post a warning, issue a new grimoire, and rest. No 
> key
> revocation, no key generation, no signing of the new key. No keyservers 
> either.

No... that's not going to cover the actual risk from this attack you
identified, and neither hashes or signatures as currently supported in
sorcery can protect against this attack.

1) Tarball is posted upstream and is compromised before we see it.
2) We download it and believe it is legit.
3) We take a hash of it (SOURCE_HASH method) OR we sign it (guru sign
   method).

Neither method is able to detect the attack at this point, because it all
looks good.

4) At some point we learn that it was compromised.
5) At this point upstream would roll a new tarball, likely with a new name,
   and remove the compromised one.
6) We update the grimoires with the new source URL and the new SOURCE_HASH
   or signature, and probably post an alert to let users know they should
   update.  Under the sig method we also probably revoke and replace the
   signing key and any related signatures via a script.

So step 6 is more complicated for signatures, but both provide the same
protection at each stage of this attack.

So after the above has happend, what are the scenarios?

a) Users do scribe update and are good (under either method, since they're
   getting the updated hash or signature).
b) Users do not do scribe update, but don't have the source tarball
   locally.  If they try to cast the spell at this point and the filename
   hasn't changed, the updated hash or signature would both fail to match,
   and they'd get an error.  If the compromised source was removed, they'd
   also get an error.  If for some reason the compromised source is still
   there at the same URL, this becomes the same as the next scenario.
c) Users do not do scribe update, but had already summoned the compromised
   source while it was available.  At this point they have the compromised
   source and the matching SOURCE_HASH or guru sig in the grimoire.
   *Neither* method is going to catch this as currently designed, because
   the local system has in effect received no notification that it has bad
   information.

Protecting against this attack requires us to force sorcery to check for a
current list of known bad hashes or signatures or keys at a regular
interval, outside of users explicitly updating their grimoires.  Neither
method has this functionality now.  Sorcery has to add it if we want to
protect against this attack possibility.  It is probably that signatures
will be easier to extend to cover this, since they already have support for
the concept of revocation.

> To make it easier to maintain, we can agree, as Eric suggested, to support a
> single strong hash algorithm that GPG uses.
> 
> As a direct response to your question, I would go even further and forbid
> maintainers to sign tarballs. If the policy dictates using only authors'
> signatures, there's nothing to be done to protect against this attack. You 
> may
> not like it though :-). And you know what's funny? For the heck of me I 
> don't
> understand why. But let's not discuss it because it's a different subject
> altogether, and I'd prefer to stay on course.
> 
> Sergey.
> 
> Quoting "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>:
> 
> > On Aug 31, Jeremy Blosser (emrys) [jblosser-smgl AT firinn.org] wrote:
> >> This raises the point though that sorcery should be checking a gurus.gpg
> >> revocation list on the first cast of each 24-hour period or something.
> >> Note that doing the same thing with regular hashes would be more 
> >> difficult,
> >> since we'd basically have to implement the idea of a revocation list in
> >> sorcery ourselves, then publish a list of any known bad hashes for 
> >> sorcery
> >> to pull.
> >
> > On further thought we'd need to look more into what the revocation certs
> > GPG generates can be ingested by; we aren't running a keyserver.  So we 
> > may
> > need to implement some support for revocation lists ourselves regardless.
> >
> > This raises the point that this is an attack we currently can't stop via
> > GPG or hashes.  If we want to prevent it, there is work to be done
> > regardless.  This makes the question of what sorcery supports the central
> > point, as it's not a matter of not removing existing support, but adding
> > new support.  And if sorcery chooses not to implement protection for
> > regular hashes against this kind of attack you have identified, should we
> > still include any support for them if we know they are vulnerable?
> >
> 
> 
> 
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss

Attachment: pgpa5H76aUcbk.pgp
Description: PGP signature