MITM attacks against portsnap and freebsd-update
alnis.morics at gmail.com
Mon May 19 20:57:54 UTC 2014
On 05/19/2014 23:28, David Noel wrote:
> 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.
Subversion checkouts and updates take much more time than Porstnap.
> 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 (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.
> 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 pmirror.sh.
> 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 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().
> 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: http://www.freebsd.org/cgi/query-pr.cgi?pr=188428
> Freeze attacks against freebsd-update:
> Freeze attacks against portsnap:
> MITM attacks against portsnap mirrors (pmirror.sh):
> Retiring portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188433
> 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
> (http://svnweb.freebsd.org/base/user/cperciva/). 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.
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions