Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Mar 2001 06:29:57 -0500 (EST)
From:      Trevor Johnson <trevor@jpj.net>
To:        Maxim Sobolev <sobomax@FreeBSD.ORG>
Cc:        Kris Kennaway <kris@obsecurity.org>, <ports@FreeBSD.ORG>, Alistair Crooks <agc@pkgsrc.org>
Subject:   Re: new message digest support in pkgsrc (fwd)
Message-ID:  <20010312052254.X2937-100000@blues.jpj.net>
In-Reply-To: <3AAC9B99.159B7527@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> > A scheme has been described which is computationally expensive but not
> > infeasible.  See the references I gave.
>
> I did not mean md5 attack, I meant scheme of attack using trojaned distfile specially tailored in such a way
> that its md5 checksum matches original one. This attack while possible in principle, but have the following
> difficulties, that turn its possibility close to 0:
>
> - attacker should specially tailor trojaned distfile to have the same checksum as original one (md5 attack);
>
> - attacker should put trojaned distfile onto one of the MASTER_SITES;

This is as difficult as opening an account at sourceforge.net, tripod.com,
nbci.com, or geocities.com, and starting a software project which a
FreeBSD committer will consider worth adding to the ports collection.
Someone capable of breaking MD5 would surely have no difficulty.

> - attacker should ensure somehow that the victim will fetch trojaned distfile from that site;

It is almost a matter of course that the master site is listed in
MASTER_SITES, so this was taken care of already.

> - attacker should ensure that the victim will build that package.

Well, the attacker may not have a particular victim in mind.  Perhaps his
purposes would be served if he had many victims and many unaffected users.
Then it would be sufficient to let FreeBSD's package-building system
prepare the package for distribution on CD-ROM, or to choose a software
license that would prohibit packages from being distributed (perhaps one
that would prohibit mirroring).  Such licenses do not seem to raise
suspicion.

If he had a particular victim in mind, and for some reason wanted everyone
else to be unaffected, then the malicious code could check for something
particular to that victim's system(s)--its IP address, for example.  Some
social engineering might be needed in convincing the victim to install the
package, especially because it would be easiest to create a new software
project rather than subverting an existing one.  Depending on the hacker's
goals, the expense of constructing the colliding distfiles might not be
worthwhile for a single victim (except a large institutional one).
Another kind of attack would probably be more suitable, for a single
victim.

If these things were considered truly difficult, we would be using a
simple CRC check, for example cksum(1), rather than MD5 to check the
integrity of files.  That would be adequate to detect non-malicious
changes.

> > addressed as well.  Their existence is not a reason not to adopt longer
> > hashes, any more than the existence of bad drivers on the roadways is a
> > reason not to drive carefully or wear a seat belt, or even both at the
> > same time.
>
> Well, in my view another analogy is more appropriate here: existence of air bags doesn't mean that they
> should be installed on each transportation device, even where it could not help anyway, say bicycle, air
> plane, motorcycle and so on.

In MD5, we've had a 128-bit "air bag" for the "driver" since 1994
(bsd.port.mk revision 1.79).  I'm just saying that the "sodium azide" in
it is getting "stale" and I would like 160-bit ones for the "passengers"
and "side doors" like those I've seen on "newer cars".  Even though I
haven't heard of an abundance of tragic "airbag-related fatalities" with
those "cars" I'm happy to have a "disabling switch" in the design, so you
can protect yourself from the possibility.

Yes, if they gave out licenses for making analogies, mine would be
revoked, I know. :-)
-- 
Trevor Johnson
http://jpj.net/~trevor/gpgkey.txt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010312052254.X2937-100000>