Re: ~/.login_conf disabling exact reasons wanted
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=1mid=215381start=2001-09-19end=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. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 15:11:17 +0400, Andrey A. Chernov wrote: If you mean his report in BUGTRAQ http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=215381start=2001-09-19end=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. Why it is hoax? One reason is simple, look at his examples: default: :copyright=/etc/master.passwd: or :welcome=/etc/master.passwd: in user's ~/.login_conf. --- Only me class can be defined in ~/.login_conf, anything else ignored there. And me class picked up only when permissions are set to user mode, at the end of setusercontext(). And copyright and welcome are not overwriteable from me class in any case. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): Why it is hoax? One reason is simple, look at his examples: A hoax, that has been tested and verified by 10+ people on IRC, where he originally reported it. Only me class can be defined in ~/.login_conf, anything else ignored there. And me class picked up only when permissions are set to user mode, at the end of setusercontext(). And copyright and welcome are not overwriteable from me class in any case. Yeah, now you know what is broken. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 14:12:17 +0200, Alexander Langer wrote: Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): Why it is hoax? One reason is simple, look at his examples: A hoax, that has been tested and verified by 10+ people on IRC, where he originally reported it. Please, read me carefully. This bug not exist in -current, where it is disabled by mistake via commit I complain. I not test other branches, I mean -current. Proper fix will be to commit -current libutil/login_cap to other branches, not disable it, especially in -current. Only me class can be defined in ~/.login_conf, anything else ignored there. And me class picked up only when permissions are set to user mode, at the end of setusercontext(). And copyright and welcome are not overwriteable from me class in any case. Yeah, now you know what is broken. It is working in -current. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): Please, read me carefully. This bug not exist in -current, where it is disabled by mistake via commit I complain. I not test other branches, I Err, the bugtraq message explicelty says 4.4. Even worse if it only exists in the production-branch. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 15:11:07 +0200, Alexander Langer wrote: Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): Please, read me carefully. This bug not exist in -current, where it is disabled by mistake via commit I complain. I not test other branches, I Err, the bugtraq message explicelty says 4.4. Even worse if it only exists in the production-branch. Well, to be more carefull I'll need to say that it is hoax _for_-current_ as described. Proper move will be MFC -current login_cap variant to other branches, not disabling not testing rush. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): [Cc: listed trimmed to a value mass] Proper move will be MFC -current login_cap variant to other branches, not disabling not testing rush. If I understood the IRC discussion a week ago correctly, we had a volunteer who wanted to rewrite the whole login_cap stuff anyways. I don't remember who, though, and it might also be the case that I'm completely mistaken. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
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=1mid=215381start=2001-09-19end=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
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 13:53:02 -0400, Robert Watson wrote: 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 I test in on my current -current changing copyright and welcome to various values and using default and standard and me but can't reproduce this bug. Please tell me EXACT how you test in in -current. To be double sure, you can check out very recent -current libutil and try it temporary moving your libutil out of the way. Could anybody else confirm this bug persent on very recent -current or not present? If this bug not present in very recent -current, I prever very recent login_cap merge into each branch instead of simple disabling. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 22:42:43 +0400, Andrey A. Chernov wrote: On Sat, Sep 22, 2001 at 13:53:02 -0400, Robert Watson wrote: 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 I test in on my current -current changing copyright and welcome to minus your disable, of course. various values and using default and standard and me but can't reproduce this bug. Please tell me EXACT how you test in in -current. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 22:42:43 +0400, Andrey A. Chernov wrote: On Sat, Sep 22, 2001 at 13:53:02 -0400, Robert Watson wrote: 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 I test in on my current -current changing copyright and welcome to various values and using default and standard and me but can't reproduce this bug. Please tell me EXACT how you test in in -current. To be double sure, you can check out very recent -current libutil and try it temporary moving your libutil out of the way. Could anybody else confirm this bug persent on very recent -current or not present? Sorry for all that buzz, I am finally able to reproduce it on -current. I can't do it previously simple because I don't have empty login class field in /etc/passwd. This happens only with empty class field in passwd and default class in ~/.login_conf. This is NOT the way LOGIN_CAP supposed to work. It supposed to work as I describe in previous messages. I'll work on the proper fix tomorrow. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
The bug doesn't exist in 4.4 either. It was fixed prior to release. Doesn't anyone read commit mail anymore?! :-( - Jordan Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): Please, read me carefully. This bug not exist in -current, where it is disabled by mistake via commit I complain. I not test other branches, I Err, the bugtraq message explicelty says 4.4. Even worse if it only exists in the production-branch. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 03:17:52PM +0400, Andrey A. Chernov wrote: Only me class can be defined in ~/.login_conf, anything else ignored there. And me class picked up only when permissions are set to user mode, at the end of setusercontext(). And copyright and welcome are not overwriteable from me class in any case. I was able to overwrite the settings for the `default' class, which happens to be my login class, and was able to get master.passwd to print... This was 4.x though, not CURRENT, so maybe this is something that wasn't affected in CURRENT, and that's what you're referring to, or something. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
In message [EMAIL PROTECTED], Joseph Mallett writes: On Sat, Sep 22, 2001 at 03:17:52PM +0400, Andrey A. Chernov wrote: Only me class can be defined in ~/.login_conf, anything else ignored there. And me class picked up only when permissions are set to user mode, at the end of setusercontext(). And copyright and welcome are not overwriteable from me class in any case. I was able to overwrite the settings for the `default' class, which happens to be my login class, and was able to get master.passwd to print... This was 4.x though, not CURRENT, so maybe this is something that wasn't affected in CURRENT, and that's what you're referring to, or something. I am able to exploit the bug in 4.4-RC. I am not able to exploit 4.4-RELEASE. Regards, Phone: (250)387-8437 Cy SchubertFax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ~/.login_conf disabling exact reasons wanted
On Sat, Sep 22, 2001 at 05:21:24PM +0400, Andrey A. Chernov wrote: On Sat, Sep 22, 2001 at 15:11:07 +0200, Alexander Langer wrote: Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): Please, read me carefully. This bug not exist in -current, where it is disabled by mistake via commit I complain. I not test other branches, I Err, the bugtraq message explicelty says 4.4. Even worse if it only exists in the production-branch. Well, to be more carefull I'll need to say that it is hoax _for_-current_ as described. Proper move will be MFC -current login_cap variant to other branches, not disabling not testing rush. This problem was reported to us at almost literally the very last minute..it was after Jordan had slipped several release dates already, and at least one of those postponements was because other security problems. There was no time to do a more thorough fix; now that the release is out we can revisit it, as was the intention all along. Kris PGP signature
