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] [thread-next>] [day] [month] [year] [list]
Date: Sat, 19 Feb 2005 09:41:36 -0800
From: <dullien@....de>
To: "Darren Reed" <avalon@...igula.anu.edu.au>
Cc: "Robert Sussland" <robert@...wood.org>,
	"Gadi Evron" <gadi@...ila.gov.il>, <bugtraq@...urityfocus.com>
Subject: Re: SHA-1 broken


Hey all,

> And what about the case for (uncompressed) binary images ?

Base64-encode them before hashing.

On top of that, let me sketch under what scenario a collision on binaries is
relevant:

Mallory generates a collision-byte-string, a and a'. In order to do anything
evil she has to construct two innocent-looking executables containing these
strings of which one has to be signed. She can then replace the "good" 
version
with the "evil" version. So far the theory. Now how does the practical part 
of
it look ?

Let's begin this by fixing one assumption:
1) Whoever signs the executables is sane, e.g. will refuse to sign 
executables
that he cannot analyze, e.g. stuff that depends on self-decrypting code etc. 
He
will furthermore reject executables containing non-standard constructs 
(stuff that
a compiler won't emit, which is relatively easy to check).

Claim: a and a' have to be valid, executable code in order for Mallory to
be evil. Reasoning: If a and a' are merely data, the program containing them
has to interpret them, and as such have all the code (API calls etc) that is 
later-on
used for evil deeds present in the executable (both the "good" and the "bad" 
one),
and a sane signer won't sign them.
Now we have a really tight restriction on a and a', namely that it is valid, 
executable
code does not contain anything a compiler wouldn't emit. Wow. Try generating 
a
collision with that :-)

I am not trying to claim that the attacks aren't a major breakthrough, but 
unless
someone goes out produces better collisions or solves second preimage MD4
(or better), we need not be overly worried.

Cheers,
Thomas Dullien 



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ