On Feb 23, 2017, at 2:57 PM, Alice Wonder <al...@domblogger.net> 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@centos.org
https://lists.centos.org/mailman/listinfo/centos
