Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Jun 2002 12:13:32 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        "H. Wade Minter" <minter@lunenburg.org>
Cc:        Benjamin Krueger <benjamin@seattlefenix.net>, freebsd-security@freebsd.org
Subject:   Re: Much ado about nothing.
Message-ID:  <Pine.NEB.3.96L.1020626120250.6618W-100000@fledge.watson.org>
In-Reply-To: <20020626113517.N3133-100000@bunning.skiltech.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020626120250.6618W-100000>