Re: The Pointlessness of the MD5 "attacks"
I thought the usual attack posited when one can find a collision on a source checksum is to make the desired change to source, then tinker with something less obvious and more malleable like lsbits of a UI image file until you find your collision on two input source packages. Adam On Tue, Dec 14, 2004 at 10:17:28PM +, Ben Laurie 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. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The Pointlessness of the MD5 "attacks"
Ondrej Mikle wrote: On Tue, 14 Dec 2004 14:43:24 +, 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. 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. 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. 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. 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. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The Pointlessness of the MD5 "attacks"
On Tue, 14 Dec 2004 14:43:24 +, 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). It can be based on variable modification using buffer overflows, integer overflows, strange side effects of expression evaluation, etc. 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. > 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. 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..."). Ondrej Mikle - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
The Pointlessness of the MD5 "attacks"
Dan Kaminsky's recent posting seems to have caused some excitement, but I really can't see why. In particular, the idea of having two different executables with the same checksum has attracted attention. 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. 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. You may as well have it ping a website to find out whether to misbehave. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]