Date: Tue, 4 Dec 2007 12:26:53 -0600 From: Josh Paetzel <josh@tcbug.org> To: freebsd-security@freebsd.org Subject: Re: MD5 Collisions... Message-ID: <200712041226.57303.josh@tcbug.org> In-Reply-To: <lVc62oiBymnab8lBALlx8g@JGrbVcNo5fKy4Wexs9u5RQ> References: <20071203154412.461d0faf@meijome.net> <200712041010.35935.josh@tcbug.org> <lVc62oiBymnab8lBALlx8g@JGrbVcNo5fKy4Wexs9u5RQ>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart4085718.YkimdDvLxy Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 04 December 2007 10:43:45 am Eygene Ryabinkin wrote: > Josh, good day. > > Tue, Dec 04, 2007 at 10:10:32AM -0600, Josh Paetzel wrote: > > > The usefullness of this with application to the ports collection > > > is questionable, since you should make two colliding archives and > > > both of them should be unpackable and the second should do some > > > evil things. But strictly speaking, there are attacks producing > > > files with the same size and MD5 hash. > > > > > > http://www.cits.rub.de/MD5Collisions/ is also a good reading. > > > > It's not really questionable....for all practical purposes it's > > worthless. In order to generate meaningful same-length collisions you > > need control of the original file. (Your links go to lengths to explain > > this...) In the case of a ports distfile if you have control of the > > original file you really don't need to go to great lengths to generate > > collisions, you can simply toss your malicious content in there right > > from the get go. > > Yes, thanks for clarifying the point that one should be able to control > both sequences in order to produce colliding files with the same size. > > But there is at least one scenario, when such attack is useful, if > one will be able to produce two colliding source archives. Suppose, > I am providing a port with new sources (either the new port or an > update to the current one) and I am controlling the source tarballs. > The sources will be supposedly reviewed by some parties and they > will find no backdoors in it. So the port comes in the systems and > it is thought to be good and useful. > > Once the port proved itself, I am replacing the good source tarballs > with the evil ones (remember, I had prepared two colliding archives) > and no one will notice the difference with MD5 + size check. But new > port installations will be doing something different from the sources > that were reviewed. > > Again, this is only theoretical thing with many preconditions, but > if I am able to make two colliding archives, then other things are > not very hard to achieve. People are producing colliding X.509 > certificates, so we have an example of not 'just junk colliding > content', but something meaningful. > > I am not going to flame about the real possibility of doing these > for many reasons, and the first one that it is no longer doable for > the current ports where SHA256 is in the game. All I wanted to say > that there are scenarios where one can exploit MD5 weakness, providing > one can extend MD5 collision attacks to archives. > > Shutting up. Well, your point is well made, correct, and a realistic scenario (depending= on=20 your paranoia level) I totally agree with the original links posted. We know MD5 has problems,= =20 it's only a matter of time before a really significant one is discovered,=20 therefore it makes sense to avoid using it whenever possible even if the=20 current problems don't seem to affect your use-case. =2D-=20 Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB --nextPart4085718.YkimdDvLxy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHVZvxJvkB8SevrssRAsI9AKCFtXkmeOrWikYg0FgUR7ZPr3GeGwCeM7nt BhjisrX/+804MGGY/uVHMto= =UZXW -----END PGP SIGNATURE----- --nextPart4085718.YkimdDvLxy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712041226.57303.josh>