There is a new repository attack that signed commits introduce. We
should consider, this attack, if only to document it and consider best
practises on detecting and reducing the risk.
The basic attack is to tamper with the GPG signature, with the goal of
deliberately causing signature validation to fail. There are a couple of
scenarios I can think of immediately:
A mischievous attacker simply wants to ruffle some feathers. No actual
harm is done, it's simply a nuisance. Everything could grind to a halt
until the most recent backup is restored (would this be classifed as a
denial-of-service attack?). As a variation, a malicious hacker could
employ this 'mischief attack' repeatedly, in the hopes that eventually
people will ignore the error. Once that happens, the attacker can then
slip in an actual exploit and users will assume it's the same annoyance.
In second scenario, the attacker is actually a trusted individual who
has legitimate access to the repository. Mallory, a disgruntled
employee, commits code that contains some nastiness hidden among valid
changes. The committed nastiness is signed as usual. After the commit,
Mallory modifies the signature embedded in the RCS file. If the
nastiness goes undiscovered, Mallory gets away with it. If the nastiness
is discovered, the GPG signature validation will fail, and Mallory can
claim that the code she checked in did not contain the exploit, and
someone else must have inserted the exploit, thereby invalidating the
signature.
There are probably many other scenarios that we can invent involving
signature tampering.
Signature tampering can be foiled (or at least discovered forensically)
if the signature itself can be included in the 'loginfo' notifications.
I would propose adding a '%g' format specifier to loginfo, which would
insert the GPG signature. Thoughts? Comments?
--
Jim
_______________________________________________
Bug-cvs mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/bug-cvs
