From owner-freebsd-security Wed Jun 26 9:13:50 2002 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B694137B401 for ; Wed, 26 Jun 2002 09:13:34 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g5QGDWw6004214; Wed, 26 Jun 2002 12:13:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 26 Jun 2002 12:13:32 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "H. Wade Minter" Cc: Benjamin Krueger , freebsd-security@freebsd.org Subject: Re: Much ado about nothing. In-Reply-To: <20020626113517.N3133-100000@bunning.skiltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 26 Jun 2002, H. Wade Minter wrote: > On Wed, 26 Jun 2002, Benjamin Krueger wrote: > > > http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20584 > > Lemme see if I have this right. > > We were all whipped into a "Must Upgrade NOW!!!!" frenzy over this > OpenSSH hole. It was so severe that it had to be kept in utmost > secrecy, and the S.O.P. seemed to be "If you can't or won't upgrade, > then turn off SSH,"... > > ...and the solution is to disable S/KEY??? That's it? Well, I think there's more to it than that: a large part of the new functionality in new versions of OpenSSH relates to how OpenSSH handles the [inevitable] compromise. The OpenSSH code is very complicated: it integrates some of the most risky bits of systems programming into one neat package. That includes crypto implementations, network protocol handling, authentication and privilege management, etc. The privilege seperation code has the goal of reducing the risk associated with this complexity by isolating the risky bits in a sandbox. There will probably be future security vulnerabilities in OpenSSH -- in fact, given the complexity of the code, it's almost guaranteed, despite the best efforts of many developers. If privilege seperation helps manage this risk, then it's certainly desirable to deploy it. As with any new security feature, it's something that we'll want to look at very closely, since it introduces its own risks, of course. Given that it now has a demonstrated track record of reducing the scope of at least one real vulnerability, it has some pretty decent credibility already. So we'll continue with plans to get the 3.x OpenSSH code into -STABLE with privilege seperation enabled by default, and take it from there. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message