ZFS and block deduplication

[bogstad-e+AXbWqSrlAAvxtiuMwx3w at public.gmane.org (Bill Bogstad)]

On Mon, Apr 25, 2011 at 4:14 PM, Tom Metro <tmetro-blu-5a1Jt6qxUNc at public.gmane.org> wrote:
> Edward Ned Harvey wrote:
>> (2) We're assuming the data in question is not being maliciously formed for
>> the purposes of causing a hash collision. ?I think this is a safe
>> assumption, because in the event of a collision, you would have two
>> different pieces of data that are assumed to be identical and therefore one
>> of them is thrown away... ?And personally I can accept the consequence of
>> discarding data if someone's intentionally trying to break my filesystem
>> maliciously.
>
> I think the attack vector would be along the lines of an attacker
> identifying one or more blocks of a privileged executable, creating
> replacement blocks that have both malicious code and cause a hash
> collision. They write the blocks to disk, and after the executable
> restarts, they have control.
>
> Far fetched, but if they can do it, the consequences are more than just
> some corrupted or discarded data.

True.   And depending on the design it's possible dedup could work that way.
OTOH, why write new 'copies' of the exact same data to disk?  Why not just
discard the user's trojan write request and note that the data is
already written to disk?
That way you save not only disk space, but also IO bandwidth, etc.
Now if you are doing
retrospective dedup of your disk rather then real-time (perhaps during
low usage windows),
then an attack like this could work depending on which copy of the
nominally 'identical' blocks is
retained.  If you assume random winner selection on hash collisions,
and you write the trojan
block multiple times to the disk between dedup windows you can
increase your chance of winning to
any probability you want.

Alternatively, if you can find a way to know what the blocks in a new
executable are going to be before it is installed to the local system;
you can write
out your trojan block(s) before hand and win in either the real-time
or retrospective dedup
configuration.   This could be done by monitoring security updates/new
version releases
and getting there first.

All of this assumes a way to not only generate hash collisions, but to
do so while retaining some
control over the content of the block.   This happened to MD5.  I
don't know enough to
say if SHA2/256 could someday be subject to similar attacks.

Bill Bogstad