Foiling MITM attacks on source and ports trees
cpghost at cordula.ws
Fri Jan 2 18:03:50 UTC 2009
On Fri, Jan 02, 2009 at 11:26:45AM -0600, Matt wrote:
> On Fri, Jan 2, 2009 at 10:44 AM, cpghost <cpghost at cordula.ws> wrote:
> > Hello,
> > with MITM attacks  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.
> >  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.
> Something like this was discussed back in September:
> I haven't tried Max's script yet, but it looks like it should do at
> least some of what you're looking for.
It's a beginning for sure. I assume (403 error) Max generates and
saves digests on his snapshots and the verification script does the
same locally and simply compares both lists.
In an extended version, it could grep for the digests in the
increasingly big list on Max's site...
But that's not ideal because:
1) There's no guarantee that Max's csup has not been MITM-ed itself.
2) Max can't csup EVERY revision to digest it in near real-time.
3) Even with SSL on his site, I'd prefer a digitally signed list. ;)
With this version of the script, it's not possible to check the
integrity of an arbitrary specific snapshot in time (say, starting
with the subversion migration and later).
That's why I'm thinking of (file, revision, digest) tuples, and
not just (file, digest) tuples that would need to go in that list;
and a logic to fetch a subset of the list, based on revision numbers.
The main problem I see here with (file, digest) tuples, is how to
guess the right revision number of the local file. Unless that is
transferred alongside csup (into a metadata directory? /var/db/sup
perhaps?), it will be necessary to check a local file against a list
of "known and good" digests -- the list created from the repository
out of all revisions that ever existed for that file --.
This is good enough against casual MITM, where an attacker creates his
own replacement files, but it's not good enough if the attacker merely
substitutes a current file with an older (but legitimate) file that
contains a vulnerability. That old file would verify OK because it has
a valid digest, but it's still not the file that should be in the
See the problem?
Cordula's Web. http://www.cordula.ws/
More information about the freebsd-questions