Re: GPG-signed commits: a new exploit to consider

[Derek Price]

Jim Hyslop wrote:

> 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.


I'm not sure where you are going with this one.  If the attacker already
has direct access to the repository, the signature tampering will give
them away and this will be a good thing - we are one up from before
GPG-signatures.

If the attacker is an authorized user (already authenticated via
SSH/pserver/whatever), then the signature tampering will give them away
and this will be a good thing.  They could have tampered before
GPG-signatures and it would not have been noticed.

If the attacker is an unauthorized user (already authenticated via
SSH/pserver/whatever), then the tampering will give them away and this
will be a good thing.  They could have tampered before GPG-signatures
and it would not have ben noticed.


> 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?


Yes, the loginfo hook (and probably a corresponding commitinfo hook)
would be a good thing, though without it we would still be one-up from
before GPG-signatures since Mallory's tampering would not have even
shown up as a bad signature before.  Also, Mallory will need direct
access to the repository do do this tampering and even authorized
committers will often not have that in many setups.

One problem with the loginfo hook is that I was planning on storing
binary GPG-signatures when possible.  They are smaller and would, at the
least, look ugly on the command line, and I'm not sure what embedded
NULs would do.  There would be some overhead to ASCII-Armoring the
signatures for passage to loginfo.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:derek@ximbiot.com>