Re: Checksums for git repo content?

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



On Feb 23, 2017, at 2:57 PM, Alice Wonder <alice@xxxxxxxxxxxxxx> wrote:
> 
> I think the issue is that you not only have to create a trojan file that matches the same hash, but you have to create a trojan file that matches the same hash and doesn't break compiling.

No, that’s the easy bit.  If I want to replace this line of C code:

    ++i;

with this:

    system("dd if=/dev/zero of=/dev/sda bs=1m");

the attack presented by Google shows that you merely need to modify the evil version of the file (the Git checkin, in this case) until it matches the good version according to SHA1, which is spoofable given sufficient resources.  Those resources let you fuzz the patch until you succeed:


    system("dd if=/dev/../dev/zero of=/dev/sda bs=1m");
    system("dd if=/dev/zero of=/dev/sda”); /* 0tt^V&Y3qeF3qIGlUS */

etc.

That’s why this is considered a collision attack rather than a second-preimage attack: both versions of the data can be adjusted until you find a collision, rather than just the new version of the data.

> Bottom line is git needs to move to sha256 but I do not believe there is any present danger.

There is present danger.  Just not for the git.centos.org use case, for the reasons I laid out in my other reply.

> I'd be more worried about fraudulently issued TLS certs

TLS has other defenses that prevent this attack from working against it:

    https://news.ycombinator.com/item?id=13715349

We’ve been to this rodeo before.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux