On 07/11/2012 05:33 PM, Bob Friesenhahn wrote: > 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.
True, but that may not be enough to produce a practical collision for the reason that while you know which bytes you want to attack, these might not line up with ZFS disk blocks (especially the case with Windows VMs which are store in large opaque zvols) - such an attack would require physical access to the machine (at which point you can simply manipulate the blocks directly). -- Saso _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
