Date: Wed, 26 Jun 2002 21:17:41 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Chris Knight <chris@aims.com.au> Cc: freebsd-security@freebsd.org Subject: RE: Wow Message-ID: <Pine.NEB.3.96L.1020626205731.17483E-100000@fledge.watson.org> In-Reply-To: <012e01c21d6c$e16ce9c0$020aa8c0@aims.private>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Jun 2002, Chris Knight wrote: > > If people want to do something useful, looking for nits in our > > integration of the new OpenSSH code in -CURRENT would be useful, as > > we're in the process of merging to -STABLE and catching the nits > > sooner rather than later would really be preferred. In particular, > > looking for any issues with PAM would be useful, and with non-default > > authentication types (hardware authentication tokens, kerberos, etc). > Isn't the merge a little bit hasty? According to the advisory, the least > intrusive change to -STABLE would be to uncomment the > ChallengeResponseAuthentication in /usr/src/crypto/openssh/sshd_config. > The PAM issues appear to only be in 2.9.9+. Also, my understanding of > the advisory is that the exploit hasn't been fixed - it's just that > Privilege Separation will limit the exploit to a chrooted environment > with minimal permissions. Please correct me if I'm wrong. There are several levels of response that we could take to this vulnerability. They include no action (bad idea), minimalist workarounds, minimalist corrective patches, and SSH upgrades. Now that the actual vulnerability information is available, we're in a much better position to make an informed decision--previously the only "known safe" activity was to perform a complete OpenSSH upgrade, since insufficient information was available to do a minimalist approach. - The *specific* vulnerability described in this advisory does not exist in the version of OpenSSH shipped in -STABLE. This means the most minimalist acceptable response would be to make no change at all, but an upgrade of OpenSSH is also possible. - The *specific* vulnerability described in this advisory does exist in the version of OpenSSH shipped in -CURRENT. Therefore we must make a change to -CURRENT, and that response was originally limited to "upgrade" but now could include more minimalist things. It's worth noting that the scope for "upgrade" has also expanded since the bug was originally pseudo-announced. The OpenBSD project has shipped two updates to OpenSSH lately: 3.3p, which made privilege seperation a functional reality on additional platforms, and 3.4 more recently, which actually fixes the specific bug. The OpenBSD Project held off on releasing 3.4 to permit more broad adoption of 3.3 and privilege seperation before providing specific information on the vulnerability. So here's where this leads me, anyway: - Upgrade FreeBSD 5.0 to OpenSSH 3.4. We upgraded to 3.3p immediately in response to the initial vulnerability report. We should now complete the upgrade process to bring it to 3.4 now that is available. This will move us from the "bug present but low impact" back into the "bug not present" category for that branch. - Upgrade FreeBSD 4.x-STABLE to OpenSSH 3.4. Although the specific vulnerability doesn't affect the specific version in -STABLE, we are aware that the model adopted by the older versions of OpenSSH is more prone to this sort of failure: that is, vulnerabilities resulting in privielge escalation. Given that more recent versions of OpenSSH have seen more extensive code review, and many "this is bad so fix it even though it might or might not be exploitable" types of commits, this seems like a logical direction once its stability has been demonstrated. We're in the process of working on this now. - For now, no change on the RELENG_4_X branches, adopting the most minimal safe approach avoiding suceptibility to all specifically published vulnerabilities. Once OpenSSH 3.4 is in -STABLE, evaluate its stability and functionality as a potential target for RELENG_4_X branches in the context of a non-specific security advisory (this might sound familiar to anyone watching the US news :-). Hope that we can do it in the form of a non-specific advisory as opposed to a specific one. In particular, it's worth noting that the proposed 'ChallengeResponseAuthentication' workaround actually has no security benefit in -STABLE [that I am aware of] due to when the bug was introduced in the OpenSSH branch. Therefore, other than for -CURRENT, this is not a useful work-around. Adopting the privsep model may well help us with future vulnerabilities in OpenSSH--something I think we can feel likely will exist at some point. I hope this sheds a bit of light on the strategy. 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.1020626205731.17483E-100000>