Date: Fri, 02 Jan 2009 17:30:12 +0000 From: Vincent Hoffman <vince@unsane.co.uk> To: cpghost <cpghost@cordula.ws> Cc: freebsd-questions@freebsd.org Subject: Re: Foiling MITM attacks on source and ports trees Message-ID: <495E4F24.80209@unsane.co.uk> In-Reply-To: <20090102164412.GA1258@phenom.cordula.ws> References: <20090102164412.GA1258@phenom.cordula.ws>
next in thread | previous in thread | raw e-mail | index | archive | help
cpghost wrote: > Hello, > > with MITM attacks [1] on the rise, I'm concerned about the integrity > of local /usr/src, /usr/doc, and /usr/ports trees fetched through csup > (and portsnap) from master or mirror servers. > > [1] http://en.wikipedia.org/wiki/Man-in-the-middle_attack > > There's already a small protection against MITM on the distfiles in > ports: distinfo contain md5 and sha256 digests. This is an excellent > idea that could be extended to *all* files in /usr/src, /usr/doc, and > /usr/ports. > According to http://www.daemonology.net (the creator of portsnap and also freebsd-update as well as being the freebsd security officer's website) and a quick look though the freebsd-update and portsnap scripts, both portsnap and freebsd update provide reasonable cryptographic protection from MITHM attacks. ({freebsd-update,portsnap}.conf contains a sha256 hash of the rsa key used to sign the updates) Admittedly this doesn't give a file by file checksum but does give reasonable protection against MITM attacks for updates of the ports tree and the -RELEASE src trees. Vince > What I'd like to have is a way to check the fetched /usr/src, > /usr/doc, and /usr/ports files against a *digitally signed* list of > (file, revision, digest) tuples that would be generated on-the-fly and > on-demand, so that any modification of the files in transit would be > detected (provided the checker program runs on an uncompromised host, > of course). > > This should not only apply to up-to-the-minute current files, but also > to files fetched, say, a few weeks or months ago (e.g. because they > are deployed in stable production servers). > > Assuming there's a secure way (which is not affected by MITM) to > obtain a master public key (GnuPG key) of the FreeBSD Project, it > would be nice to have a mechanism in place that would: > Agreed, a more secure way of getting it than http://www.freebsd.org/security/so_public_key.asc would be nice, (just ssl would make me happy.) > 1. create a compressed list of (file, revision, md5/sha1/...digest) > tuples for /usr/src, /usr/doc, and /usr/ports trees, > > 2. sign this list with the master private key of the project and > make it available. > > Because the number of revisions for any specific file can be huge, > this list could grow very fast. It may be economical to have the > program create only (file, revision, digest) tuples for a limited > number of revisions, typically as many as needed between start and end > of a typical csup run on slow links, or at most, say, 24h... starting > at an arbitrary date in the past. > > To save CPU cycles, previous computed (file, revision, digest) > tuples could be permanently cached in an RDBMS, in Subversion or > wherever else that's appropriate. > > Oh, we could always use SSL between csup and the servers as fallback, > but SSL is not without flaws and I doubt that all mirrors would have > valid certificates, defeating the whole purpose of foiling MITM > attacks. And SSL alone doesn't permit checking "after the fact" > the integrity of an older snapshot. > > Any idea? Could this be implemented as a plugin to Subversion (since > it must access previous revisions of files and previously computed > digests)? Given read-only access to the repository, a set of simple > Python scripts or C/C++ programs could easily implement the basic > functionality and cache the results for fast retrieval by other > scripts. But how well will all this scale? > > Thanks, > -cpghost. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?495E4F24.80209>