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 <[EMAIL PROTECTED]>
> > 
> > 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
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to