Ticket History #667: Possible major security problem with Kerberos V on Digital Unix

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 <bugs@RT-11.MIT.EDU>; 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: <Pine.OSF.4.05.9811301426450.15478-100000@dogbert.cc.ndsu.NoDak.edu>
Date: Mon, 30 Nov 1998 16:36:22 -0600 (CST)
From: Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu>
To: cert@cert.org, krb5-bugs@MIT.EDU
Subject: Possible major security problem with Kerberos V on Digital Unix

Dec Alpha w/ C2 security
login.krb5 and kshd do not use setluid properly.

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 <hartmans@MIT.EDU>
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: GNATS administrator <gnats-admin@RT-11.MIT.EDU>, 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 <epeisach@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: Ezra Peisach <epeisach@MIT.EDU>,
GNATS administrator <gnats-admin@RT-11.MIT.EDU>, 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 <hartmans@MIT.EDU>
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: GNATS administrator <gnats-admin@RT-11.MIT.EDU>, 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 <tlyu@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: Ezra Peisach <epeisach@MIT.EDU>,
GNATS administrator <gnats-admin@RT-11.MIT.EDU>, 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 <epeisach@MIT.EDU>
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 <mooney@dogbert.cc.ndsu.nodak.edu>
To: Ezra Peisach <epeisach@MIT.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 16:20:58 -0600 (CST)

On Thu, 17 Dec 1998, Ezra Peisach wrote:


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

[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 <username>

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