From owner-freebsd-security@FreeBSD.ORG Wed Jul 9 18:55:07 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D88D1065675 for ; Wed, 9 Jul 2008 18:55:07 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id D51AA8FC16 for ; Wed, 9 Jul 2008 18:55:06 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id E944A5C68; Wed, 9 Jul 2008 14:57:32 -0400 (EDT) Date: Wed, 9 Jul 2008 14:57:32 -0400 From: Wesley Shields To: Chris Palmer Message-ID: <20080709185732.GK92109@atarininja.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> <20080709183325.GE55473@noncombatant.org> <20080709185405.GJ92109@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080709185405.GJ92109@atarininja.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-security@freebsd.org Subject: Re: BIND update? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2008 18:55:07 -0000 On Wed, Jul 09, 2008 at 02:54:05PM -0400, Wesley Shields wrote: > On Wed, Jul 09, 2008 at 11:33:25AM -0700, Chris Palmer wrote: > > Wesley Shields writes: > > > > > In the security world there is a balance which must be maintained between > > > providing information to consumers so that they may plan accordingly, and > > > not providing too much information so that the attackers can write > > > exploits; this is the sensitive nature of the information which often > > > leads to opaque processes by security teams around the world. > > > > http://en.wikipedia.org/wiki/Kerckhoffs'_principle > > > > Malware authors create exploits based on information they gleaned by reverse > > engineering the binary patches released by Microsoft. They are able to get > > these exploits into the wild before everyone has even had a chance to apply > > the patches, even though the patching is (semi-)automated. > > I'm well aware of that, as I have many friends who do this for a living > (legitimate businesses). I'm also not sure how this applies since the > project is open source - the fix is published at the time of the patch, > so there's no reverse engineering to do. If anything this illustrates > that patches should be applied in a timely manner in an open source > project, since the window you are describing is effectively zero. > > > Not only is there no security through obscurity, there isn't even any > > obscurity. :) > > The point is to not give hints about where in the code the problem lies > while at least being able to give the consumers of FreeBSD a chance to > plan around any potential bugs. Given the sensitive nature of the > issue, and the fact that some things are under NDA, I'm not entirely > sure it is a good idea. I'd like to see a more transparent process > without causing any harm to it, but I'm not sure how to do that right > now. > > Despite me wanting to see this happen I think these issues are too big > to overcome without more thought. I'm considering this issue closed for > now. Oh, and as I've stated to Remko privately: I think the security team is doing a good job. I, in no way, mean to suggest otherwise. I'm just trying to allow the consumers of FreeBSD a bit of wiggle room with regards to planning. ;) -- WXS