MITM attacks against portsnap and freebsd-update

[David Noel]

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 its
SHA256 verification. 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 decompression libraries an attacker who was MITM-capable could
compromise any FreeBSD system running portsnap or freebsd-update.
2. The portsnap mirroring script (pmirror.sh) 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.

Solution Summary

1. A re-working of the snapshot hashing and hash verification process.
2. The addition of hashing and hash verification code to pmirror.sh.
3. The server-side inclusion of date-stamps, and strict client-side
enforcement of expiration policies.
4. Retire portsnap.

Details

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

Retiring Portsnap

With the inclusion of svnlite in 10 I think the valid question comes
up as to whether we really need the portsnap system or whether 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 reason I see for it to be retired is that subversion allows us to
easily and securely check out the ports tree. It's a one-line command:
`svn co https://...`. Keeping it up-to-date it is another one-liner:
`cd /usr/ports; svn update`. With the inclusion of svnlite in base,
the portsnap code and servers acting as mirrors become redundant and
seem like a waste of resources.

PR's

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 free 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:
http://www.freebsd.org/cgi/query-pr.cgi?pr=188429
MITM attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188428
Freeze attacks against freebsd-update:
http://www.freebsd.org/cgi/query-pr.cgi?pr=188434
Freeze attacks against portsnap:
http://www.freebsd.org/cgi/query-pr.cgi?pr=188430
MITM attacks against portsnap mirrors (pmirror.sh):
http://www.freebsd.org/cgi/query-pr.cgi?pr=188432
Retiring portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188433

David Noel