[3009] in Kerberos-V5-bugs
pending/667: Possible major security problem with Kerberos V on Digital Unix
daemon@ATHENA.MIT.EDU (Tim Mooney)
Mon Nov 30 17:37:51 1998
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: gnats-admin@rt-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU,
Tim Mooney <mooney@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
>Number: 667
>Category: pending
>Synopsis: Possible major security problem with Kerberos V on Digital Unix
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Mon Nov 30 17:37:00 EST 1998
>Last-Modified:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>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 <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
