Re: [task #4633] GPG-Signed Commits

[Derek Price]

Jim Hyslop wrote:

> This does complicate things somewhat on the client side. Instead of
> simply signing the file and creating a detached signature, the client
> has to sign [header info]+[file].


I'm afraid that is unavoidable if replay attacks are going to be detected.

>> No, wait, if an attacker has root access to the CVS server, revision
>> numbers become untrusted.  Really all you're trying to achieve is to
>> identify the real culprit, so that Eve can't frame Alice.
>

[. . .]

> At this point, I don't think we're entirely clear on what we are
> trying to achieve. It may be helpful to list the specific attacks we
> are trying to protect against. Some of the attacks have been discussed
> in threads on this list, but it would be nice to have it all collated
> in one place.


I think we are discussing replay attacks, inserted at any of a number of
locations:

   1. The first and most obvious is an authenticated malicious client
      (compromised or otherwise) attempting to replay an earlier commit
      session (its own or someone else's), presumably because it
      contains exploitable code.
   2. Next would be someone with access to a compromised server
      attempting to replace archive revisions with old, signed revisions
      (effectively equivalent to a compromised server which just sends
      the wrong, replayed data in response to client requests).


Justin, Joshua, Sylvain, I believe this is a good explanation of the
concerns you approached me about?

It occurs to me that in my replay-attack analysis so far, I have mostly
neglected to consider a compromised server (case 2 above).  In this
case, the server cannot be relied on to enforce that each client signs
the same sequence id it was passed because the server cannot be trusted.

In this case, the server cannot even be trusted to pass the correct
revision number for a file to the client on checkout, so having the
client sign the new revision number is useless.  The attack here would
be that, when replaying revision 1.7, simply tell the client it is
receiving revision 1.7, even though it should have gotten 1.12.  The
client may not know the difference, for instance it had requested the
HEAD revision or the like, and would happily verify the compromised
revision 1.7.

I understand where the sequence identifiers that were suggested to me
are going, but I am not sure how to enforce them without a trusted
server.  On simple updates, without a tag specified, the client could
verify that the sequence number is increasing, but this still leaves a
lot of leeway for an attacker and provides no protection at all for `cvs
up -r TAG' (including updates without an explicitly specified tag but
using a sticky tag from a previous update that has moved since that update).

I suppose a signed sequence number would still provide some auditability
after the fact.  A client might have trouble extracting much extra
information from a sequence number in a single update (or worse,
checkout) operation, but making sure that revisions were in order and
that all revisions were validly signed could be invaluable to a forensic
analysis.

There is still at least one weakness to this defense: a compromised
server could muddy the waters by setting its sequence counter back to a
low number, waiting for some number of valid commits to occur, then
inserting the replay attack, then allowing commits to continue.  This
could make the replay a little harder to spot but folks should still be
able to detect that something is wrong and narrow the search space to a
range of revisions.

This question remains: is there enough value to only handing out
sequence ids on commit rather than handing them out with every session
and clients only using them for commits?  i.e., is there really a value
to having seq ids (S), or even signed revision numbers, like scenario 1:

1.1 (S1) --- 1.2 (S2) --- 1.3 (S4) --- 1.4 (S6)
              |
              \- 1.2.2.1 (S3) --- 1.2.2.3 (S5)

Over a simpler-to-implement but still always-increasing scenario 2 like:

1.1 (S1) --- 1.2 (S21) --- 1.3 (S47) --- 1.4 (S68)
              |
              \- 1.2.2.1 (S31) --- 1.2.2.3 (S52)


Keep in mind that in scenario 1, revisions may be deleted anyhow. 
Scenario 1 also increases the amount of work the server has to do and
adds a turn-around to the client-server communication.  Given signed
revision numbers, scenario 1 does allow a little more of the archive
structure to be reconstructed securely, but it opens up the possibility
of revision 1.X of some other file being replayed to replace revision
1.X of a file.

Signing a unique sequence number for each file in the commit, as opposed
to each session as previously discussed, as well as the revision number,
could mitigate some of this problem, but it still introduces the extra
communication turn-around.  A sequence number and the file path could be
signed without introducing the turn around, but this would limit users
to `mv file newname && cvs rm file && cvs add newname' as a method of
renaming files until CVS supports renames of both directories and files
as part of the protocol and repository format.

I still think that the simplest way to verify the repository integrity
after the fact is to maintain a mirror of changes via commitinfo/loginfo
and compare it to the contents of the repository via some external
toolset periodically.

I'm willing to agree that adding a session identifier + file path
element to the signed data could be useful, keeping in mind that this
could invalidate signatures if admins rename, copy, or add links to
files in the repository.

I'm still reluctant to add the new revision number to the signed data
since it involves an extra turnaround in client-server communication.  I
am willing to reconsider this if anyone can provide a description of a
dangerous exploit involving a weakness in the secure session id + path
solution, maintained in conjunction with a secure commitlog off the CVS
server.

> Signing the delta makes each commit atomic, with no dependencies on
> the validity of previous versions. In effect, Alice says "These are
> the specific changes I made, and this is the result." 


Again, not very valuable to a single client, but potentially valuable to
a forensic analysis.  You are wrong about having no dependencies on
previous versions, however.  A signed delta cannot be used to construct
its revision of a file unless all other deltas in the chain are valid.

>> Are the GPG folk listening in on this convo?  Are there discussions on
>> sci.crypt or comp.software.config-mgmt that I can follow?
>
>
> Not that I'm aware of. Is it worth cross-posting this discussion to
> one of these forums?


I'm not sure of the likely level of interest or likelihood of response
from any of these groups.

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>