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: Seth Alan Woolley <seth AT positivism.org>
  • To: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Threat profile analysis for spackages not signed by authors
  • Date: Wed, 31 Aug 2005 16:00:15 -0700

We can spend all day coming up with attack vectors:

Hash is modified in our SCM by a rogue box owned by a developer:

hashes:

just edit the file and p4 submit it with a version update

+0

hashes, signed by guru and regular signatures:

have to get to the passphrase before you can do the above
or
you have to modify the gurus.gpg key in the repo (watched like a hawk)

+0.5

Personally, signed by guru anywhere is acceptable to me. HOWEVER, I've
proposed ways to resolve this conflict: 1 is with DETAILS signing, and 2
is with anonymous key names with a clickthrough wrapper over the
security policy to find the identity. 2 is cleanest (and not everybody
has to participate), but 1 is "I'll put up with it". Sergey seems to
have rejected number 2.

I fear though we'll lose Sergey if the clean method is proposed, but I
just don't see any reason why he can't use the clean method other than
an irrational fear or out of spite.

Lastly, we all need to let our egos take a step back and let Sergey and
Arwed think about for a bit before pushing somebody to a decision. I
hope all that's needed to be said has been said at this point and a
little reflection will resolve the situation.

It seems Arwed gets to decide which path we take -- the Clean or the
DETAILS (or entire spell) signature method (we really can't do a
PGP-based scm at this point) if Thomas isn't going to pipe in. I'd like
unanimity from Leads in every policy change such as this.

Seth

On Wed, Aug 31, 2005 at 08:06:25AM -0400, Sergey A. Lipnevich wrote:
> Hi All,
>
> This is an attempt to explain why do I think that even on technical merits,
> without any philosophical issues, using signatures is not better than using
> hash values. Our goal is to verify integrity of the package, and I consider
> possible threats to that.
>
> Assumptions:
> a1) tarball was not signed by its author(s);
> a2) we're using the same hash function as the signature algorithm, except
> when
> using signatures the hash is additionally signed, and *only* signature is
> included in the grimoire;
> a3) maintainer's network is not compromised, or if it is, another maintainer
> will quickly notice that;
> a4) grimoire tarball (and sorcery too) is signed with GPG signature.
>
> Please note that I am only interested in hashes and signatures on individual
> source packages, not authors' signatures, grimoire/sorcery package
> signatures,
> or any other.
>
> Whether the authors publish a hash value for their package or not may or
> may not
> be important in each case. Also, hash of the original tarball may or may not
> collide with the compromised one. Scenarios are as follows:
>
> s1. The tarball is published, then compromised after we added to the
> grimoire.
> s2. The tarball is published and compromised immediately.
> s3. The tarball is published and not compromised, but user's local network
> is
> exploited to make him/her download a compromised copy.
> s4. The tarball is published and not compromised, but user's local network
> is
> exploited and the user downloads both malicios tarball and modified grimoire
> tarball.
> s5. SMGL site is compromised, the grimoire tarball with hashes/signatures is
> replaced.
>
> In scenario 1, hash value and a signature would both detect the breach. If
> there's a hash collision. If there's a collision, both hash and signature
> detect nothing. Hash +1, signature +1.
>
> In scenario 2, hash value would have to be replaced when the breach is
> discovered. If the tarball is signed by SMGL maintainer, the signature has
> to
> be replaced, and the key might have to be revoked, and new key must be
> created.
> If users disable GPG verification, e.g. because they don't have always-on
> Internet access, or they don't want to use GPG, they are running the
> additional
> danger on never learning that the tarball is tainted. Hash +1, signature +.5
> (with .5 subtracted because of the extra hassle).
>
> In scenario 3, the story runs pretty much the same as scenario 1, including
> the
> variant when the collision was found by the attacker. Hash +1, signature +1.
>
> In scenario 4, there are two possibilities. 4a) attackers control every
> aspect
> of the user's network; 4b) attackers don't control the network good enough
> to
> prevent checking of GPG signature. 4a is less likely, but in this case it
> doesn't matter what the user does because s/he is in parallel universe:
> everything looks and works exactly like attacker wants it to, and there's no
> way find out the truth. Hash 0, signature 0. In 4b, attacker's attempt is
> thwarted by the signature. But which signature is that, on the spell or on
> the
> grimoire tarball? On the grimoire tarball of course. So zero for signatures
> on
> individual packages here as well: hash 0, signature 0.
>
> Scenario 5 is easily detected by the grimoire tarball signature. Because
> neither
> hash values nor signatures of individual tarballs play any role here, zero
> to
> both.
>
> The total count is +3 for hashes, +2.5 for signatures. I hereby conclude
> that
> SMGL maintainer signatures on individual source packages are not in any way
> better than strong hash values, in detecting the integrity violations of
> said
> packages.
>
> Thank you for attention.
>
> Sergey.
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733

Attachment: pgpRw5XpS4yaw.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page