[darcs-users] patch file naming

David Roundy droundy at abridgegame.org
Sat Mar 20 12:00:55 UTC 2004

On Fri, Mar 19, 2004 at 12:15:31PM -0500, Zooko O'Whielacronx wrote:
> I'm trying to understand the potential problem.
> Darcs decides whether a patch has already been applied by comparing the
> patches "name", which is a secure hash of some metadata.
> Since the name does not (perhaps can not) be securely bound to the actual
> contents of the patch, an attacker could trick a darcs repository into
> thinking that it had applied a patch, when instead it had applied a
> different patch of the same name.
> This could open up the way for a malicious person to insert code into my
> source code which is different than the code I think he is inserting.
> That is: he could send me a darcs patch, I could examine it and conclude
> that it does something safe and useful, and apply it to my repository,
> but because the repository has been corrupted by an earlier application
> of a misnamed patch, when I apply it the result is different than I
> expected.

There are two attacks that (I think) I discussed.  Just corrupting their
own repo doesn't gain the attacker anything over simply sending you a
custom-made (corrupt) patch.

The vulnerability would require that the attacker give two differing
patches with the same name to two trusted developers (and would require
that both be accepted).  Then these two developers would have inconsistent
darcs trees.

Then the attacker would have two options.  There is the easy-to-understand
option, and the more-effective-but-harder option.  The first is to send a
patch to one of the developers which is correct on his repo, but which will
introduce a vulnerability on the other developer's repo due to the
inconsistency between their repos.  The other is to plan ahead (before
introducing the corruption) by looking at the two developers' repos and
seeing a patch which exists in one repo, but not in the other, and which
can be converted into a security hole by introducing a shift in its
position in the file.  So then the attacker need only convince both
developers to both apply the corrupt pair of patches before sharing the
pre-existing patch with one another.

On the plus side, this kind of trick would most likely be noticed, as most
likely another patch would end up failing to work on one or the other of
the repos.  So for this to be effective, the attacker would want to choose
a file that is rarely modified.
David Roundy

More information about the darcs-users mailing list