On Wed, 11 Jul 2012, Sašo Kiselkov wrote:
The reason why I don't think this can be used to implement a practical
attack is that in order to generate a collision, you first have to know
the disk block that you want to create a collision on (or at least the
checksum), i.e. the original block is already in the pool. At that
point, you could write a colliding block which would get de-dup'd, but
that doesn't mean you've corrupted the original data, only that you
referenced it. So, in a sense, you haven't corrupted the original block,
only your own collision block (since that's the copy doesn't get written).
This is not correct. If you know the well-known block to be written,
then you can arrange to write your collision block prior to when the
well-known block is written. Therefore, it is imperative that the
hash algorithm make it clearly impractical to take a well-known block
and compute a collision block.
For example, the well-known block might be part of a Windows
anti-virus package, or a Windows firewall configuration, and
corrupting it might leave a Windows VM open to malware attack.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
