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

Re: dpkg-sig support wanted?



* Henning Makholm:

> Scripsit Florian Weimer <fw@deneb.enyo.de>
>> * Jochen Voss:
>
>>> I found the example at http://www.cits.rub.de/MD5Collisions/ quite
>>> impressive.  They have two different valid PostScript files with
>>> identical MD5 sums.  I don't know how much computing time they used,
>>> though.
>
> They claim a few hours:
>
> | Based on [WY05] and the analysis described in [Da], we implemented
> | an attack to find random collisions for the MD5 compression
> | function. It took just a few hours on a customary PC.

I can no longer recall if this paragraph was present in the original
version of the page; I didn't notice it when I read it for the first
time.

>> None, many of these examples were created before the collision
>> generation tools were generally available.
>
> They did create or use a collision, as anyone can verify simply by
> downloading the files.

One collision was published by Wang et al. as a zero-knowledge proof
of their discovery.  I thought they had reused this one, like many
others did.

>> The "exploit" uses some properties of Postscript files which make
>> them not very desirable for storing electronic documents which
>> cannot be altered.
>
> There is absolutely no reason to put the word exploit in scare quotes
> here.

Strictly speaking, you cannot exploit MD5 itself, you can only exploit
security systems that rely on some property of the MD5 function.

Let's look what happens in the attack published by the RUB
researchers:

  1. The attacker creates two Postscript files with the same MD5 hash.
  2. The attacker submits one of the file to the victim.
  3. The victim views the file in his Postscript viewer, doesn't notice
     anything strange, and signs it.
  4. The attacker obtains the signature, and uses it together with the
     second file he has created.

A successful attack is possible if the following conditions are met:
(a) the attacker can create a suitable collision, (b) the victim uses
the document supplied by the attacker, (c) the victim only checks one
presentation form of the document, and (d) the document is used in a
way which does not lead to the victim disputing the signature, and
into investigation (which would immediately reveal the attack).

It turns out that we can actually do without (a).  Have a look at the
attached Postscript with your favorite Postscript viewer, and sign it
if you agree with its message. 8-)

In my opinion, this modified attack strongly suggest that the process
described above is already substantially broken.  MD5 is just a weak
part among others.  As a result, the attack doesn't show what people
claim.

Just be clear: I don't claim everything is alright with MD5.  For most
applications, you should definitely migrate to something else (what is
a different question).  But most organization's resources are limited,
you can't afford to migrate too often, and you deal with many issues
at once.  Correctly analyzing the relevance of security issues is very
important.  Misleading claims about the impact of new attacks are not
helpful, may lead to wrong allocation of resources, and prevent more
important vulnerabilities from being addressed.

> You might want to notice that the "properties" you apparently think
> invalidate the example are also shared by many common formats for
> software. An ELF binary can easily be crafted to contain a blob of
> initialized data whose contents are only used for checking whether to
> enable some malicious machine code that is always present - and this
> would not be easily detectable at all.

In general, any form of malicious code is not easy to detect.  But the
malicious code must be present in the first place.  You can use a MD5
collision to make it dormant, but it has to be there.

This means that it's dangerous to commit yourself to the contents of a
document, using a digital signature, unless you fully understand the
meaning of each byte in the document.

>> (Note the "rub.de" part of the URL.  A clear warning sign.)
>
> The nice thing about ad hominem arguments is that you can make them
> without ever having to argue the merits of your case.

*shrug* The computer security folks at that university started
spreading FUD about various security systems, mainly rehashing the
work of others.  They seem to be in it mostly for the publicity.

Attachment: psgQN6abYG4d.ps
Description: PostScript document


Reply to: