MITM attacks against portsnap and freebsd-update

David Noel david.i.noel at
Mon May 19 20:28:33 UTC 2014

I shared this with the freebsd-security mailing list last month but
didn't achieve my goal of finding a Bourne-savvy programmer who was
willing to take on this bug. I'm posting it here to address a larger
audience and hopefully find someone who has the time free to come up
with some patches for us.


I found a few bugs in portsnap and freebsd-update that I'd like to
bring to the community's attention and hopefully recruit people to
help fix. I mentioned them to Colin (their author) a few years ago and
he agreed that they're issues that need to be addressed, but in the
time since neither he nor I have been able to get around to fixing
them. I'm hoping that someone reading this is able and willing to
pitch in. I've also taken this to secteam@, but no one there's made
any progress on them in the past 6 months so I figured it was time to
approach the broader community. Surely there's a benevolent sh-savvy
hacker out there who has time to take these on. They're pretty simple
fixes -- the functionality that's needed exists in the scripts
already, it just needs to be reused in a few key places.

I also think it would be an appropriate time to discuss retiring portsnap.

Problem Summary

1. Both portsnap and freebsd-update extract fetched data prior to
SHA256 verifying it. The extraction libraries used have a long history
of bugs so it's reasonable to assume there might be more. Both
freebsd-update and portsnap are run as root. Using a vulnerability in
the extraction libraries an attacker who was MITM-capable could
compromise any FreeBSD system running portsnap or freebsd-update.
2. The portsnap mirroring script ( lacks of any sort of
mechanism to verify the data prior to processing and mirroring it.
Without this, mirrors are open to compromise via methods similar to
those found in the client-side scripts (decompression library
exploitation). It also means an attacker could feed a mirror a corrupt
archive, opening users of that mirror to compromise.
3. Both portsnap and freebsd-update are vulnerable to freeze attacks.
4. The addition of subversion in base makes portsnap redundant.
5. The default implementation of the portsnap build code leaves users
vulnerable to MITM attacks.

Solution Summary

1. A re-working of the snapshot hashing and hash verification process.
2. The addition of hashing and hash verification code to
3. The server-side inclusion of date-stamps, and strict client-side
enforcement of expiration policies.
4. Begin phasing out portsnap.
5. Switch the default subversion URL to HTTP Secure.


The functions of concern in are fetch_snapshot(),
fetch_update(), and fetch_snapshot_verify().
The lines of concern in are 99-103, 121-125, 138-149, and
153-157 (using revision 257073).
The functions of concern in are fetch_metadata(),
fetch_files_premerge(), and fetch_files().

The changes will need to apply to those sections of code and the
corresponding code in the build scripts.

Retiring Portsnap

Given the inclusion of svnlite in 10 and the amount of effort required
to fix these bugs I think the valid question comes up as to whether we
really need the portsnap system. My position is that it could be
safely retired. Obviously if the conclusion of that discussion is that
we don't need it then these bug fixes would be unnecessary.

The main argument I see for it to be retired is that subversion allows us to
do everything portsnap does and more; it allows us to easily and
securely check out the ports tree. Checking out the repository is a
one line command: `svn co https://... /usr/ports`. Keeping it
up-to-date it is another one-liner: `svn update`. With the inclusion
of svnlite in base, the portsnap code and servers acting as mirrors
seem redundant and a waste of resources.


I've avoided filing PR's to give myself, Colin, or secteam@ the chance
to fix these bugs first. Since none of us have had the time to do
so and because I'm now sharing these bugs publicly with the list I
figure it would be an appropriate time to file PR's for them.

MITM attacks against freebsd-update:
MITM attacks against portsnap:
Freeze attacks against freebsd-update:
Freeze attacks against portsnap:
MITM attacks against portsnap mirrors (
Retiring portsnap:


In a later email I pointed out that the portsnap build code pulls the
ports tree from subversion using http vs https. This makes ports trees
fetched via portsnap vulnerable to MITM attacks and potential
corruption as well. A member of the Security Team, Xin Li was kind
enough to look into this and brought to our attention that the actual
portsnap build system is running a somewhat modified version of the
scripts found in Colin's subversion directory
( The changes applied
to those scripts tell the build system to fetch all files from svn via
spiped, in theory securing them from MITM attacks. I have not
personally reviewed the spiped code so I am not certain whether
transport via spiped truly secures the data transfer.

There remains the question of whether the portsnap mirror scripts were
modified similarly in production.

Regardless, anyone using the build and mirror scripts found on svn is
vulnerable to attack, so privately run portsnap mirrors using those
scripts should be treated accordingly.


The good news is that these are relatively simple fixes. Colin's code
is clean, efficient, and aside from these small oversights very well
written. Another thing that makes this an easy fix is that the
functionality that's needed exists elsewhere in the code, so there are
plenty of good examples to work from. It's virtually a copy/paste job,
but not quite that simple.

If no one here is able to pick these up it's not the end of the world
-- I'll get around to them eventually. But for now I'm poor and
unemployed, so every free moment of productive time I have is going
towards projects that contribute towards taking care of my life's
basic necessities.


More information about the freebsd-questions mailing list