full-disclosure - Re: MD5 algorithm considered toxic (and harmful)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fe37588d0712011931m6d2a5930i3302cfd4441e5ace@mail.gmail.com>
Date: Sat, 1 Dec 2007 19:31:53 -0800
From: "Kristian Erik Hermansen" <kristian.hermansen@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: MD5 algorithm considered toxic (and harmful)

On Dec 1, 2007 7:08 PM,  <Valdis.Kletnieks@...edu> wrote:
> Admittedly, MD5 is on its last legs.  However, please note that the current
> state of the art for MD5 collisions is "create two plaintexts that collide
> with the same (but unpredictable) MD5 hash".  That's what these binaries
> demonstrate.

Correct...

> What is still *not* known to be doable is "given a plaintext that has a
> pre-specified MD5 hash, compute a second plaintext with the same hash".
> So publishing the MD5 hash of the binary is still safe - for now.

But is it?  Let's create a thought experiment.  Let us first assume
that an internal security product release engineer has access to the
source code, the product binaries, and is responsible for creating ISO
images and MD5 hashes to accompany them for distribution to government
agencies which will utilize the security product internally.

OK, now let's say that this release engineer wants to create two
different ISO images, each with a different AUTORUN feature on the
disc.  Since he has the ability to choose the hash here, then we must
therefore conclude that MD5 will not actually ensure that the disc is
legitimate and unaltered.  Now, such an attack is not as sexy as
colliding with a pre-formed MD5 hash, but we do know that
approximately 70% of exploited security issues somehow involve
internal personnel.

> If I was a vendor, I'd be publishing both MD5 and SHA-256 for the data.

So my question to you then is why even bother with MD5, and not just
choose to use SHA-256 instead?  In fact, I might even go so far to say
that future Linux distributions should stop including the md5sum
program in default installations.  I say this because it correlates
with the "secure by default" motto.  If the user really needs md5sum,
they can install it separately.  The only issue is that both
applications are included in coreutils, so it is unlikely that they
would ever be separated.

> (Note that strictly speaking, what you *really* want is a PGP-signed or
> otherwise authenticated MD5/SHA-256 hash.  Otherwise, if I'm an attacker,
> I can just splat a new binary up, and a new MD5SUMS file that lists the
> MD5 sum for the backdoored binaries.  If anything, more people manage to
> screw *this* part up than the much lesser offense of still using MD5 rather
> than something from the SHA-2 family)....

Yeah, storing your MD5 and binary on the same asset is just like
keeping your important security logs on a system that was just
compromised.  Your data is tainted...
-- 
Kristian Erik Hermansen
"I have no special talent. I am only passionately curious."

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/