The Pointlessness of the MD5 "attacks"

[Jay Sulzberger]

On Tue, 14 Dec 2004, Ben Laurie wrote:

> Ondrej Mikle wrote:
>> On Tue, 14 Dec 2004 14:43:24 +0000, Ben Laurie <ben at algroup.co.uk> wrote:
>> 
>>> But the only way I can see to exploit this would be to have code that
>>> did different things based on the contents of some bitmap. My contention
>>> is that if the code is open, then it will be obvious that it does
>>> "something bad" if a bit is tweaked, and so will be suspicious, even if
>>> the "something bad" is not triggered in the version seen.
>> 
>> 
>> There are many ways to obfuscate code so tha it will seem innocent,
>> see for example International Obfuscated C Code Contest
>> (http://www.ioccc.org/main.html).
>
> That does not make it seem innocent, it makes it seem incomprehensible.

No.  The C library, running on hardware without serious defenses, is
sufficiently obscure, that one more possibility of spoofing makes things
worse.

>
>> It can be based on variable
>> modification using buffer overflows, integer overflows, strange side
>> effects of expression evaluation, etc.
>
> I agree, but you do not need MD5 attacks to achieve these things.

Yes, but having a crack for a crypto hash makes all these things easier.

>
>> Another possibility for an attacker is the use of deliberate and very
>> rare race conditions, which only attacker knows how to trigger. Race
>> conditions are very difficult to discover. Cf. Linux ptrace race
>> condition 
>> (http://archives.neohapsis.com/archives/bugtraq/2001-10/0135.html).
>> It's been there in kernels 2.2.0 - 2.2.19 and 2.4.0 to 2.4.9. It
>> allowed for local privilege escalation. Took quite a long time to
>> discover it, even though it was open source code. Quite a long time
>> for opportunity, if we assumed an attacker would do similar attack
>> deliberately.
>
> Again, MD5 does not improve these attacks.

It can help disguise such attacks.

>
>>> So, to exploit this successfully, you need code that cannot or will not
>>> be inspected. My contention is that any such code is untrusted anyway,
>>> so being able to change its behaviour on the basis of embedded bitmap
>>> changes is a parlour trick.
>> 
>> 
>> That's true in theory, but it's different in real world. Take
>> Microsoft software as an example. Many banks use their software (and
>> sometimes even military). I don't think that all of them reviewed
>> Microsoft's source code (I guess only a few, if any at all). There was
>> an incident of a worm attacking ATMs.
>
> No, and they are therefore vulnerable to Microsoft. Note that MD5 is not 
> required for Microsoft to attack them.

Again, the MD5 crack helps.  Here one attack is obvious: third parties may
more easily make substitutions of code.

>
>> Another example, Enigma was being sold after WW 2, but the Allies knew
>> it could be broken. The purchasers did not. Same as when US army sold
>> some radio communications that used frequency hopping to Iraq during
>> 1980's. US knew that it could be broken ("just in case...").
>
> And MD5 helps with this how?
>
> Cheers,
>
> Ben.

The MD5 crack helps here in several ways.  Perhaps the most important is
that if MD5 is thought to be uncracked, that simple MD5 checking might be
considered so safe that no second check is used, at points where a second
and third check would help, thus opening up a possible avenue of attack.
Indeed, even before MD5 was widely known to be cracked, competent security
folk often recommended that several hashes be used since in most
applications the cost of computing hashes is small.  One point to remember
is that the published cracks are likely only a small part of the cracks
known to well funded professionals.  The parallel to the case of the weak
Enigmas is that many people buying the weak Enigmas thought they were
uncracked, else they would not have bought them.  Despite the recent
published MD5 cracks, it is clear that the most interesting cracks of MD5
are as yet unpublished.

oo--JS.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com