|Subject:||GPG-signed commits: a new exploit to consider|
|Date:||Thu, 22 Sep 2005 11:19:17 -0400|
|User-agent:||Mozilla Thunderbird 1.0.6 (Windows/20050716)|
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?
|[Prev in Thread]||Current Thread||[Next in Thread]|