From owner-freebsd-questions@FreeBSD.ORG Mon May 19 20:57:54 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72CCDD8A for ; Mon, 19 May 2014 20:57:54 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD32B271C for ; Mon, 19 May 2014 20:57:53 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id pv20so4593481lab.13 for ; Mon, 19 May 2014 13:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cAM6C6iZoiPxh9Kd7NVlu9aFKbCjwfoBLIu5BcSf04c=; b=QhOjkeD58rf/d3+yOwCGAyuPw0saemlZ0R2I8I2bqk2bkwe7gawcpgPgUEa8nzfpPd EU9oWiQQwQk40n8jexOnHWdqPLsbv9n7Sq5iJ+4XJtEA52XBh/e/x4rU0USElU5paDr1 nws31fAVrNtop78odTfyiVsTV2inUxmEiJuSq6c9xIY5Cw3TFpWi3+C33wSkeLlUVadx VMbPCY7K0VV5ceIi3tOsnRU0cz1bBlvXaDDTpGu8vajbuge0zkp/b82ERRYHJc4iRZBH ACf0b7Nxz/pu5jMQGmyS0P2nS1AnIplw9BAA7wv7JmIqTWbpCBQOI/nPKSv7J3PhMllL 4T/Q== X-Received: by 10.152.26.99 with SMTP id k3mr3719607lag.68.1400533071889; Mon, 19 May 2014 13:57:51 -0700 (PDT) Received: from blazon-pc.rw.local ([78.84.244.14]) by mx.google.com with ESMTPSA id ui5sm18721641lbb.32.2014.05.19.13.57.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 13:57:50 -0700 (PDT) Message-ID: <537A704D.6010209@gmail.com> Date: Mon, 19 May 2014 23:57:49 +0300 From: Alnis Morics User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: MITM attacks against portsnap and freebsd-update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 20:57:54 -0000 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. -Alnis > 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. > > 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(). > > 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. > > 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 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 > > --- > > 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. > > -David > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"