Date: Sat, 22 Sep 2001 13:53:02 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: security@FreeBSD.ORG, current@FreeBSD.ORG, developers@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: ~/.login_conf disabling exact reasons wanted Message-ID: <Pine.NEB.3.96L.1010922133112.39778A-100000@fledge.watson.org> In-Reply-To: <20010922151116.A82718@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Sep 2001, Andrey A. Chernov wrote: > On Sat, Sep 22, 2001 at 14:39:43 +0400, Andrey A. Chernov wrote: > > As commit/immediate MFC message says: > > > > Disable per-user .login_conf support due to incorrect merging of local > > and globaly settings. An alternative implementation will be developed. > > > > Reported by: Przemyslaw Frasunek <venglin@freebsd.lublin.pl> > > > > Where I can see his report? Really I don't understand all that rush with > > ~/.login_conf disabling which breaks locale f.e. > > If you mean his report in BUGTRAQ > http://www.securityfocus.com/cgi-bin/archive.pl?id=1&mid=215381&start=2001-09-19&end=2001-09-25 > > it is hoax, we don't have such vulnerability in -current as I test. > Please TEST things before commiting, especially to all branches. > Please back it out. This vulnerability is not a hoax--spreading this kind of mis-information is at best unhelpful, and more likely quite harmful. It was verified by a number of FreeBSD developers on many of past releases, and on 4.4-RC, as well as FreeBSD 5.0-CURRENT. The patch was tested on many of those branches, and as such committed. My FreeBSD -CURRENT boxes largely run -CURRENT from August, and those were certainly vulnerable--I cannot speak to more recent -CURRENT, as I relied on others to test the change on the most recent -CURRENT. If more recent -CURRENT is not vulnerable, I would be happy to back out the patch on -CURRENT. You can expect a security advisory on the vulnerability within the next couple of days, as well as the usual foray of binary updates and patches. We considered it of prime importance to make sure that the vulnerability was not present in 4.4-RELEASE, which we believe (as a result of these commits) that it is not. However, in response to your suggestion that an immediate MFC of your changes was appropriate: I believe that the two options were either to apply a work-around that was absolutely guaranteed to fix the problem, or to postpone the release to evaluate a complete solution, assuming we knew one existed. Given that a clear workaround was available, and given that the time to properly evaluate a complete fix would be non-trivial (I would feel uncomfortable with less then a week to fully understand and test the necessary changes), the decision was made to go ahead with the work-around, especially in light of impending public release of information on the vulnerability. As I'm sure you are aware, the code managing this component of the login process is both at high risk (it is exposed to both untrusted I/O and user files) and complex (it manages a suite of credentials, resource limits, and authorization criteria). This workaround reduces the risk by reducing exposure to untrusted policy sources--the fix will require extensive review. So, to put it bluntly: during the final release process, it would be irresponsible to MFC security fix code in -CURRENT that may not have been reviewed, and was apparently written without the knowledge that it was fixing a security hole. And if you did know it fixed a potential security hole, I'd like very much to know why it was you didn't report this immediately to the security-officer so that we could propagate the fix and release an advisory. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.1010922133112.39778A-100000>