From owner-freebsd-security@FreeBSD.ORG Mon Jan 28 08:07:33 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BCF8B1C3 for ; Mon, 28 Jan 2013 08:07:33 +0000 (UTC) (envelope-from andre.rekovic@gmail.com) Received: from mail-ia0-x241.google.com (mail-ia0-x241.google.com [IPv6:2607:f8b0:4001:c02::241]) by mx1.freebsd.org (Postfix) with ESMTP id 9753CF86 for ; Mon, 28 Jan 2013 08:07:33 +0000 (UTC) Received: by mail-ia0-f193.google.com with SMTP id k27so1427436iad.0 for ; Mon, 28 Jan 2013 00:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=dyF1iw8zcCBZn5KESlpHSv5ODDV7r3ebNJK/UPC8Qw0=; b=mNbmKm6crYIplg27LzDGKlCmAHAIvkv72q0+Njc15TzqzAfq+4OOuJEPofxAQrALHf NQyDbvxnq/2irT03HiTZaSRwzScFM1FUlqzCTOZLNkYKodA+VxuC1p/JV+2WDTiy71ro TXDPfj1F1gqyUpFck2OQMTNLYVtX7wK+PgJx/5HjSBdGYuWX9x3T6nctHuUVhTxWYFH0 xPNpy7SzRKcD78royGF6WcgzYbGbanpX8XAmsfiX8hlxWjKQO0Fe/cqCJMMI5H0Nof/P J+fTcyfSCX//0+AU+3v2zLx7rfPcl14KQvHcQGLOJBM8ZZeUnk8HS0XF67r7IiM6ExSp UJPg== MIME-Version: 1.0 X-Received: by 10.50.34.193 with SMTP id b1mr4506763igj.89.1359360451974; Mon, 28 Jan 2013 00:07:31 -0800 (PST) Received: by 10.64.42.42 with HTTP; Mon, 28 Jan 2013 00:07:31 -0800 (PST) Date: Mon, 28 Jan 2013 19:07:31 +1100 Message-ID: Subject: Is portsnap secure or isn't it? (2012 compromise and general reflections) From: Andre Rekovic To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 08:07:33 -0000 Hi, I've been trying to make sense of the details on the 2012 compromise given here: http://www.freebsd.org/news/2012-compromise.html To be honest, I find that page very disappointing and wish it had the clarity of a FreeBSD security advisory. With the advisories, there's never been a time I've read the background, problem description, and impact sections and then thought "huh?" I've always understood the threats. Not so with the above page, which is a tangle of details. I use only freebsd-update(8) and portsnap(8) for updates. I don't use packages; I compile from ports. I last used portsnap in August, which is outside the critical time window mentioned (Sep 19 - Nov 11). Presumably this means I'm OK for the incident in question, but I really have no idea based on my reading of the page. Now for the tangle of details: "If you are running a system that has had no third-party packages installed or updated on it between the 19th September and 11th November 2012, you have no reason to worry." This suggests that ports aren't affected. Someone could read the above, think "nope, I don't pkg_add packages (precompiled binaries)," and bail on the whole page. The ensuing paragraphs, especially with the mention of pkg_add, reinforce this suggestion. But obviously "packages" is used in a loose sense to include ports, because... "We unfortunately cannot guarantee the integrity of any packages available for installation between 19th September 2012 and 11th November 2012, or of any ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors." It's my understanding that any ports trees created/updated via portsnap *between 19th September 2012 and 11th November 2012* may be affected but that ports trees created/updated via portsnap a little outside of that time window should be fine. Is this right? I can't be completely sure from the above quote. "We have also verified that the most recently-available portsnap(8) snapshot matches the ports Subversion repository, and so can be fully trusted. Please note that as a precaution, newer portsnap(8) snapshots are currently not being generated." That mentions only the most recently available portsnap snapshot (at the time). Presumably there are suspect snapshots (perhaps those distributed within the critical window). "If you use portsnap(8), you should portsnap fetch && portsnap extract to the most recent snapshot. The most recent portsnap(8) snapshot has been verified to exactly match the audited Subversion repository. Please note that as a precaution, portsnap(8) updates have been suspended temporarily. Again allowing the user to infer that some snapshots are suspect. And that leads to my main query: If there are suspect snapshots, how can that be? How did portsnap security fail? Port compilation is supposed to be cryptographically secure. The distinfo files in the ports tree contain SHA256 hashes. In theory, this means you know you're getting the version of the source code the port maintainer has OK'd. The portsnap snapshot is supposed to be cryptographically secure. Assuming you don't play with the -f and -k switches, its cryptographic security hinges on the KEYPRINT in /etc/portsnap.conf. The KEYPRINT in /etc/portsnap.conf wasn't changed after the compromise, so I'm assuming there was no loss of confidence in the associated RSA public key. I can think of only two explanations for suspect snapshots: 1. An attacker pushing out earlier snapshots signed with the same key. The portsnap shell script appears to defend against this for update fetches (using the timestamp in the tag file) but allows initial fetches to grab a snapshot up to a year old. Really, if this is the only fear, I'm sure many users would rather not wipe their disks and perform a complete reinstall. 2. A deeply troubling approach to how snapshots are (or were) getting signed with the private key (picture a push-button automated signing or a manual signing accompanied by a complete lack of vigilant checking). This approach would completely undermine user confidence in portsnap. OK, fine: 3. I'm missing something ridiculously obvious and won't show my face in public for a few months. Please, could someone clear this up for us users. From owner-freebsd-security@FreeBSD.ORG Mon Jan 28 20:08:57 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B8AE3FD for ; Mon, 28 Jan 2013 20:08:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 792D588C for ; Mon, 28 Jan 2013 20:08:57 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E4663B946; Mon, 28 Jan 2013 15:08:56 -0500 (EST) From: John Baldwin To: freebsd-security@freebsd.org Subject: Re: Is portsnap secure or isn't it? (2012 compromise and general reflections) Date: Mon, 28 Jan 2013 14:09:34 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301281409.34192.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jan 2013 15:08:57 -0500 (EST) Cc: Andre Rekovic X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 20:08:57 -0000 On Monday, January 28, 2013 3:07:31 am Andre Rekovic wrote: > "We unfortunately cannot guarantee the integrity of any packages > available for installation between 19th September 2012 and 11th > November 2012, > or of any ports compiled from trees obtained via any means other > than through svn.freebsd.org or one of its mirrors." > > It's my understanding that any ports trees created/updated via > portsnap *between 19th September 2012 and 11th November 2012* may be > affected but that ports trees created/updated via portsnap a little > outside of that time window should be fine. Is this right? I can't be > completely sure from the above quote. Your assumption is correct. The root issue here is that there are two repositories that hold the ports tree, SVN and CVS. The CVS repository is updated by a script that replays each SVN commit into the CVS repository allowing downstream users of CVS via cvsup or other means to continue using the ports tree after it was switched from CVS to SVN. The issue in this case is that while the SVN repository is known to be completely fine, the CVS repository is not and is considered suspect > "We have also verified that the most recently-available > portsnap(8) snapshot matches the ports Subversion repository, and so > can be fully > trusted. Please note that as a precaution, newer portsnap(8) > snapshots are currently not being generated." The meaning of this is that we have verified that after the end date (11th November 2012), we know that the ports CVS and SVN trees are fully in sync. We also know that they are in sync going forward. However, during that window, CVS is suspect. The important point here for portsnap is that portsnap snapshots are generated from the CVS repository. > That mentions only the most recently available portsnap snapshot (at > the time). Presumably there are suspect snapshots (perhaps those > distributed within the critical window). Correct, any snapshot generated while the CVS tree was suspect is suspect. The problem here is that portsnap's trusted source was suspect. :( > I can think of only two explanations for suspect snapshots: > > 2. A deeply troubling approach to how snapshots are (or were) getting > signed with the private key (picture a push-button automated signing > or a manual signing accompanied by a complete lack of vigilant > checking). This approach would completely undermine user confidence in > portsnap. I think it is closer to the latter with the implicit assumption that the CVS repository could be trusted. I do think it is going to switch to pulling from SVN (if it hasn't already), but you still have the issue of knowing how you can trust the repository being used for snapshots. -- John Baldwin