Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 18838 From mooney@dogbert.cc.ndsu.NoDak.edu Mon Nov 30 17:36:33 1998 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA02354 for ; Mon, 30 Nov 1998 17:36:32 -0500 Received: from dogbert.cc.ndsu.NoDak.edu by MIT.EDU with SMTP id AA20672; Mon, 30 Nov 98 17:36:36 EST Received: from localhost (mooney@localhost) by dogbert.cc.ndsu.NoDak.edu (8.9.1/8.9.1) with ESMTP id QAA15444; Mon, 30 Nov 1998 16:36:22 -0600 (CST) Message-Id: Date: Mon, 30 Nov 1998 16:36:22 -0600 (CST) From: Tim Mooney To: cert@cert.org, krb5-bugs@MIT.EDU Subject: Possible major security problem with Kerberos V on Digital Unix >Number: 667 >Category: krb5-appl >Synopsis: Possible major security problem with Kerberos V on Digital Unix >Confidential: yes >Severity: serious >Priority: medium >Responsible: epeisach >State: open >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Mon Nov 30 17:37:00 EST 1998 >Last-Modified: Thu Dec 17 17:22:00 EST 1998 >Originator: mooney@dogbert.cc.ndsu.NoDak.edu >Organization: >Release: krb5 1.0 >Environment: Dec Alpha w/ C2 security >Description: login.krb5 and kshd do not use setluid properly. >How-To-Repeat: >Fix: >Audit-Trail: Responsible-Changed-From-To: gnats-admin->epeisach Responsible-Changed-By: epeisach Responsible-Changed-When: Thu Dec 10 10:32:55 1998 Responsible-Changed-Why: I have been able to reproduce the problem and will working on the fix. From: Sam Hartman To: Ezra Peisach Cc: GNATS administrator , krb5-bugs@MIT.EDU Subject: Re: krb5-appl/667: Possible major security problem with Kerberos V on Digital Unix Date: 10 Dec 1998 12:13:58 -0500 Have you confirmed that this only works with C2 enabled? If so, I realize it's a problem worth fixing, because of the consequences. However, it is somewhat emeliarated by the fact that we don't claim to support C2. If not, then this a really serious issue on Digital Unix that we may wish to issue a vendor bulletin for. From: Ezra Peisach To: Sam Hartman Cc: Ezra Peisach , GNATS administrator , krb5-bugs@MIT.EDU Subject: Re: krb5-appl/667: Possible major security problem with Kerberos V on Digital Unix Date: Thu, 10 Dec 1998 13:09:06 EST The bug exists if C2 is not enabled but the subsets are installed. The consequences then are not so bad because a user can corrupt a database which is not used by the system - unless C2 is later turned on. While we have never claimed to support C2, we have not said that we don't. I think fixing the bug is the right thing to do. People might turn on C2 believing that they are imporoving security - we should not lower the expectations. While we cannot really test everything - we can fix the big ones. The consequence of this hole would allow a mere user on a C2 system to prevent anyone else from logging in (including root) to other nasty stuff. The question I have is what should be the consequences of setluid failing. I believe we should abort on failure. In sshd it is fatal, but in our code it is not. I think there are three situations to consider: a) build on a C2 machine - run on a non-C2 machine b) build and run on a C2 machine c) build and run on a non-C2 machine. The setluid call is in libsecurity.so - this is present on Alphas with and w/o the C2 subsets installed - therefore building on a C2 vs non-C2 machine should not matter. On a non-C2 machine, the luid is set on login - therefore we should be doing the setluid call regardless. We tried to do the right think in login.c - but lose because of the optimizer removing the code testing for an unsigned integer being less than 0. I think fixing the code is appropriate. Ezra From: Sam Hartman To: Ezra Peisach Cc: GNATS administrator , krb5-bugs@MIT.EDU Subject: Re: krb5-appl/667: Possible major security problem with Kerberos V on Digital Unix Date: 10 Dec 1998 17:13:07 -0500 setleuid should certainly not be fatal in kshd if you are already the target uid (debugging) From: Tom Yu To: Sam Hartman Cc: Ezra Peisach , GNATS administrator , krb5-bugs@MIT.EDU Subject: Re: krb5-appl/667: Possible major security problem with Kerberos V on Digital Unix Date: Thu, 10 Dec 1998 18:10:35 -0500 (EST) FYI, the bug has been submitted to CERT by the original submitter.... ---Tom From: Ezra Peisach To: mooney@dogbert.cc.ndsu.NoDak.edu Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-appl/667: Possible major security problem with Kerberos V on Digital Unix Date: Thu, 17 Dec 1998 13:03:01 -0500 Here is a patch that should work against 1.0.5. (If you are using an earlier version, you may have to frob the patch a bit. The configure.in change is not really required - just for completeness. Index: Makefile.in =================================================================== RCS file: /cvs/krbdev/krb5/src/appl/bsd/Makefile.in,v retrieving revision 5.41 diff -c -r5.41 Makefile.in *** Makefile.in 1996/11/12 02:29:55 5.41 --- Makefile.in 1998/12/17 17:57:13 *************** *** 60,66 **** fi kshd: krshd.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(DEPLIBS) ! $(LD) $(LDFLAGS) $(LDARGS) -o kshd krshd.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(LIBS) klogind: krlogind.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(DEPLIBS) $(LD) $(LDFLAGS) $(LDARGS) -o klogind krlogind.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(LIBS) --- 60,66 ---- fi kshd: krshd.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(DEPLIBS) ! $(LD) $(LDFLAGS) $(LDARGS) -o kshd krshd.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(LIBS) $(LOGINLIBS) klogind: krlogind.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(DEPLIBS) $(LD) $(LDFLAGS) $(LDARGS) -o klogind krlogind.o kcmd.o forward.o $(SETENVOBJ) $(LIBOBJS) $(LIBS) Index: configure.in =================================================================== RCS file: /cvs/krbdev/krb5/src/appl/bsd/configure.in,v retrieving revision 5.78 diff -c -r5.78 configure.in *** configure.in 1996/11/12 02:28:12 5.78 --- configure.in 1998/12/17 17:57:13 *************** *** 31,37 **** krb5_cv_has_streams=no ;; alpha-dec-osf*) ! AC_CHECK_LIB(security,main, AC_DEFINE(HAVE_SETLUID) LOGINLIBS="$LOGINLIBS -lsecurity" ) --- 31,37 ---- krb5_cv_has_streams=no ;; alpha-dec-osf*) ! AC_CHECK_LIB(security,setluid, AC_DEFINE(HAVE_SETLUID) LOGINLIBS="$LOGINLIBS -lsecurity" ) Index: krshd.c =================================================================== RCS file: /cvs/krbdev/krb5/src/appl/bsd/krshd.c,v retrieving revision 5.66.2.3 diff -c -r5.66.2.3 krshd.c *** krshd.c 1997/11/18 02:54:50 5.66.2.3 --- krshd.c 1998/12/17 17:57:13 *************** *** 1313,1318 **** --- 1313,1325 ---- initgroups(pwd->pw_name, pwd->pw_gid); } #endif + #ifdef HAVE_SETLUID + /* + * If we're on a system which keeps track of login uids, then + * set the login uid. + */ + setluid((uid_t) pwd->pw_uid); + #endif /* HAVE_SETLUID */ (void) setuid((uid_t)pwd->pw_uid); /* if TZ is set in the parent, drag it in */ { Index: login.c =================================================================== RCS file: /cvs/krbdev/krb5/src/appl/bsd/login.c,v retrieving revision 5.59.2.2 diff -c -r5.59.2.2 login.c *** login.c 1997/04/03 07:35:11 5.59.2.2 --- login.c 1998/12/17 17:57:13 *************** *** 1731,1741 **** #ifdef HAVE_SETLUID /* * If we're on a system which keeps track of login uids, then ! * attempt to set the login uid, but don't get too unhappy when/if ! * it doesn't succeed. */ ! if ((uid_t) getluid() < (uid_t) 0) { ! setluid((uid_t) pwd->pw_uid); } #endif /* HAVE_SETLUID */ #ifdef _IBMR2 --- 1731,1742 ---- #ifdef HAVE_SETLUID /* * If we're on a system which keeps track of login uids, then ! * set the login uid. If this fails this opens up a problem on DEC OSF ! * with C2 enabled. */ ! if (setluid((uid_t) pwd->pw_uid) < 0) { ! perror("setuid"); ! sleepexit(1); } #endif /* HAVE_SETLUID */ #ifdef _IBMR2 From: Tim Mooney To: Ezra Peisach Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-appl/667: Possible major security problem with Kerberos V on Digital Unix Date: Thu, 17 Dec 1998 16:20:58 -0600 (CST) On Thu, 17 Dec 1998, Ezra Peisach wrote: >Here is a patch that should work against 1.0.5. (If you are using an >earlier version, you may have to frob the patch a bit. > >The configure.in change is not really required - just for completeness. As far as I can tell, this fixes the problem completely. I have verified that login via Kerberized rlogin, rshd, and telnet now correctly sets the LUID, whether or not /bin/login is replaced with the Kerberized login.krb5. Thanks for your work on this Ezra. BTW, I'm still exchanging email with security people within Digital, explaining how widespread this problem is because of the lack of information about this facet of DU security. This problem needed to be fixed in Kerberos, to be sure, but there are problems in Digital Unix that need to be fixed too, and I'm trying to influence people into making that happen. Tim -- Tim Mooney mooney@dogbert.cc.ndsu.NoDak.edu Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 >Unformatted: [This message is being sent to both the krb5-bugs mailing list and cert. I'm using the CERT vulnerability form since that asks most of the questions that are needed]. I believe I have found a major security problem in Kerberos V 1.0.5. The problem is specific to Kerberos V on Digital Unix (aka OSF/1), and also (I believe) requires that Enhanced Security (also called C2 security) be enabled on the Digital Unix machine. This problem is nearly identical to a problem is ssh from more than 2 years ago. See the comment at the top of the file ftp://ftp.cs.hut.fi/pub/ssh/ssh-osf1-c2-setluid-patch for more info. Background: Digital Unix Enhanced Security has the concept of a "Login UID", also called the "Audit ID". The idea is that when you are authenticated to a Digital Unix system using enhanced security, your login UID is set to be whatever your real UID is, and even if your UID or EUID changes, the login UID stays the same. According to the documentation, once the Login ID is set it cannot be changed. Any program that authenticates a user and changes UID to that user *must* also set the login UID before invoking a shell or command on behalf of the the user. If this is not done the Login UID remains unset, which Enhanced Security treats as UID 0, or root. Many Enhanced Security tools check *and honor* the Login UID. Programs such as /usr/tcb/bin/edauth will treat you as root when your Login UID is unset, so it's possible to use `edauth' and other tools to see all the encrypted passwds for all users, delete the enhanced security entry for a user, make changes to the enhanced security profiles for a user (even root), and possibly even create new accounts on a machine. As far as I can tell, `login.krb5' from the Kerberos V 1.0.5 distribution is the only component of Kerberos V that is aware of the Login UID. There are many other daemons (telnetd, kshd, klogind, possibly others) that do *not* set the Login UID before calling `setuid()' and exec'ing a command or shell for a user. This means that anyone that successfully authenticates via Kerberos V to a Digital Unix machine running Enhanced Security gets a shell that has no Login UID, so all Enhanced Security-aware commands run from that shell run with a Login UID of 0. The fix is to find all places in the Kerberos V source code where a daemon authenticates a user and then change uid to that user before running a command (or doing something as that user). Once those places have been identified, a call to `setluid' needs to be added before any call to `setuid()'. That's about it for background. I'll answer any questions I can regarding the problem. I noticed the problem after setting up Kerberos V on several Digital Unix machines (all running Enhanced Security). After doing a `kinit' and using Kerberos rsh to connect to a machine, `/usr/tcb/bin/edauth' shows me all enhanced security info, instead of just showing me info for myself. The CERT vulnerability form follows. Version 1.0 October 1996 CERT(sm) Coordination Center Product Vulnerability Reporting Form If you know of a vulnerability in a product, please complete this form and return it to cert@cert.org. We aren't able to acknowledge each report we receive; however, if we have additional questions, we will contact you for further information. We prefer that any vulnerability information you send to us be encrypted. We can support a shared DES key or PGP. Contact the CERT staff for more information. The CERT PGP public key is available in ftp://info.cert.org/pub/CERT_PGP.key Thanks, we appreciate your taking the time to report this vulnerability. CONTACT INFORMATION =============================================================================== Let us know who you are: Name : Tim Mooney E-mail : mooney@plains.NoDak.edu Phone / fax : (701) 231-1076 / (701) 231-8541 Affiliation and address: North Dakota State University Information Technology Services (ITS) P.O. Box 5164 Room 206 IACC Building 1320 Albrecht Blvd Fargo, ND 58105-5164 Have you reported this to the vendor? No, since it is non-vendor software. I am cc'ing the krb5-bugs@mit.edu mailing list on this, since the problem is related to Kerberos V. If so, please let us know whom you've contacted: Date of your report : Vendor contact name : Vendor contact phone : Vendor contact e-mail : Vendor reference number : If not, we encourage you to do so--vendors need to hear about vulnerabilities from you as a customer. POLICY INFO =============================================================================== We encourage communication between vendors and their customers. When we forward a report to the vendor, we include the reporter's name and contact information unless you let us know otherwise. If you want this report to remain anonymous, please check here: ___ Do not release my identity to your vendor contact. TECHNICAL INFO =============================================================================== If there is a CERT Vulnerability tracking number please put it here (otherwise leave blank): VU#______. Please describe the vulnerability. - --------------------------------- What is the impact of this vulnerability? - ---------------------------------------- (For example: local user can gain root/privileged access, intruders can create root-owned files, denial of service attack, etc.) a) What is the specific impact: On a Digital Unix (aka OSF/1) system that has MIT's Kerberos V 1.0.5 enabled and is running the various Kerberos V daemons (kshd, klogind, etc), any user authenticating via Kerberos V can run any Enhanced Security command as root. This allows someone to create, modify, and delete security information (including encrypted passwords) for all users. b) How would you envision it being used in an attack scenario: Someone could run /usr/tcb/bin/edauth -g to get the complete Enhanced Security info for all users, and then munge the output and run `crack' on it. Worse, someone could just /usr/tcb/bin/edauth to edit the Enhanced Security profile for `username' (including root). Other tools can be used as root too. Most of the tools in /usr/tcb/bin will also treat the user as root when the Login UID is unset. To your knowledge is the vulnerability currently being exploited? - ---------------------------------------------------------------- Not to my knowledge. If there is an exploitation script available, please include it here. - -------------------------------------------------------------------- Do you know what systems and/or configurations are vulnerable? - ------------------------------------------------------------- [yes/no] (If yes, please list them below) System : Digital Unix, with Enhanced Security enabled OS version : 4.0 - 4.0d, probably all versions of 3.x as well. Verified/Guessed: Verified on 4.0b, 4.0d. Are you aware of any workarounds and/or fixes for this vulnerability? - -------------------------------------------------------------------- [yes/no] (If you have a workaround or are aware of patches please include the information here.) The workaround is to disable all kshd, klogind, etc. in /etc/inetd.conf. The fix is as mentioned above -- find all instances where a daemon authenticates a user and switches UID to that user, and add a call to `setluid' before the call to setuid()'. OTHER INFORMATION =========================================================================== Is there anything else you would like to tell us? I've long had a concern that this may also be a problem with other non-vendor daemons. Any program that is started as root from /etc/inittab (including programs started from scripts in /sbin/init.d) starts with the Login UID unset. Programs like `kshd' and `klogind' that authenticate a user and then start a shell are definitely areas where setting the Login UID are important, but even daemons that don't run commands on behalf of the user may have cases where they should be setting the Login UID. For example, the Washington University IMAP daemon and the Qualcomm POP daemon both run as root and authenticate users. They should probably both be setting the Login UID, if they aren't doing that already. Any daemon on Digital Unix that links against libsecurity.{a,so} is a candidate for this type of security problem. Tim -- Tim Mooney mooney@dogbert.cc.ndsu.NoDak.edu Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164