bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPG-Signed Commits Exploit


From: Derek Price
Subject: Re: GPG-Signed Commits Exploit
Date: Thu, 29 Sep 2005 19:10:59 -0400
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Jim Hyslop wrote:

> Earlier, we discussed mechanisms for allowing loginfo access to the
> signature, so that the signatures can be stored in a secure area.
> Unfortunately for Beth, without signed deltas this mechanism pretty
> much convicts her of introducing the malicious code: Aaron checks in
> revision 1.18, its signature is stored in the secure area. Eve
> modifies rev 1.18 and changes the signature. At this point, the
> tampering could be detected *if* someone compares the signature in the
> repository against the signature in the secure area. Let's assume that
> nobody does this, though, and the rest of your scenario is followed:
> Beth commits her changes, then Eve completes her attack. 


Actually, for this defense, you don't need to store signatures
externally.  Simply storing the commit emails with attached diffs, which
many projects already generate, would be sufficient to spot this change
in the repository.  And the data would not only be stored in a
presumably secure archive, it would be duplicated in each developer's
inbox.  Of course, it might be a little less resource intensive to store
and compare signatures...  they would presumably be smaller on average
than diffs.

It's definitely a forensic defense, though.  This sort of analysis is
time consuming and would likely only be conducted at intervals or after
a compromise is detected some other way.

Even with signed diffs, it would be hard to defend against this sort of
attack on the fly on the client end without downloading the entire RCS
archive to the client and letting the client process individual diffs. 
That would be very resource intensive - as things stand, even the server
normally only needs to look at the head revision for a checkout of
HEAD.  This analysis would require examining every revision back to 1.1
with practically every checkout...  and old, expired or revoked keys
would mean that eventually even the HEAD could no longer be
satisfactorily verified.

Not sure how to do better than the forensic defense on this one and the
tools are already in place.

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>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]