Skip to Content.
Sympa Menu

sm-discuss - [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: [SM-Discuss] Threat profile analysis for spackages not signed by authors
  • Date: Wed, 31 Aug 2005 08:06:25 -0400

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.




Archive powered by MHonArc 2.6.24.

Top of Page