Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Threat profile analysis for spackages not signed by authors

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Threat profile analysis for spackages not signed by authors
  • Date: Wed, 31 Aug 2005 19:39:09 -0400

To make the long answer short, leading distributions announce such
things in their security MLs. Users are advised to download new packages
etc. I said that already.

On Wed, 2005-08-31 at 13:05 -0500, Jeremy Blosser (emrys) wrote:
> 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
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss





Archive powered by MHonArc 2.6.24.

Top of Page