On Tue, 14 Dec 2004, Ben Laurie wrote:
Ondrej Mikle wrote:
On Tue, 14 Dec 2004 14:43:24 +0000, Ben Laurie <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
