[SM-Discuss] Threat profile analysis for spackages not signed by authors
Seth Alan Woolley
seth at positivism.org
Wed Aug 31 19:00:15 EDT 2005
We can spend all day coming up with attack vectors:
Hash is modified in our SCM by a rogue box owned by a developer:
just edit the file and p4 submit it with a version update
hashes, signed by guru and regular signatures:
have to get to the passphrase before you can do the above
you have to modify the gurus.gpg key in the repo (watched like a hawk)
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.
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.
> 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
> s5. SMGL site is compromised, the grimoire tarball with hashes/signatures is
> 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
> 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
> Thank you for attention.
> SM-Discuss mailing list
> SM-Discuss at lists.ibiblio.org
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050831/2a5c8d21/attachment.bin
More information about the SM-Discuss