Ticket History #1104: potential denial of service on multi-user systems

From syl@charlotte.concordia.ca Wed May 8 15:54:18 2002
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id PAA14836
for <bugs@RT-11.mit.edu>; Wed, 8 May 2002 15:54:18 -0400 (EDT)
Received: from charlotte.concordia.ca (charlotte.Concordia.CA [132.205.121.58])
by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA19553
for <krb5-bugs@mit.edu>; Wed, 8 May 2002 15:54:17 -0400 (EDT)
Received: (from syl@localhost)
by charlotte.concordia.ca (8.9.1/8.9.1) id PAA10745;
Wed, 8 May 2002 15:54:02 -0400
Message-Id: <200205081954.PAA10745@charlotte.concordia.ca>
Date: Wed, 8 May 2002 15:54:02 -0400
From: Sylvain Robitaille <syl@alcor.concordia.ca>
Reply-To: Sylvain Robitaille <syl@alcor.concordia.ca>
To: krb5-bugs@mit.edu
Cc: Sylvain Robitaille <syl@alcor.concordia.ca>
Subject: krb5-clients: potential denial of service on multi-user systems
X-Send-Pr-Version: 3.99

Concordia University, Montreal, Quebec, Canada
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems Manager Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

System: Linux charlotte 2.2.18 #3 Fri Mar 2 16:34:15 EST 2001 i686 unknown
Architecture: i686
Also: OSF1 clyde V4.0 1091 alpha
and others


The Kerberos Credentials Cache created when Kerberos tickets are
obtained is created with a predictable file name, /tmp/krb5cc_$UID
where $UID is the user's numeric id on the system. Obviously it
needs to be this way so that kerberized clients are able to use the
cache file, but on a multi-user system, it introduces a vulnerability
to denial of service.


User "syl" is an ordinary user who just wants to authenticate his
Kerberos principle. User "test" maliciously has made sure that syl
cannot create himself a credentials cache:

: charlotte[syl] ~; id
uid=1143(syl) gid=100(iits) groups=100(iits),0(system),...
: charlotte[syl] ~; ls -l /tmp/krb5cc_1143
lrwxrwxrwx 1 test system 9 May 3 15:49 /tmp/krb5cc_1143 -> krb5_link
: charlotte[syl] ~; kinit
Password for syl@CONCORDIA.CA:
kinit(v5): Internal file credentials cache error when initializing cache
: charlotte[syl] ~; klist
klist: No credentials cache file found (ticket cache FILE:/tmp/krb5cc_1143)
: charlotte[syl] ~; ls -l /tmp/krb5cc_1143
lrwxrwxrwx 1 test system 9 May 3 15:49 /tmp/krb5cc_1143 -> krb5_link


I doubt this is a perfect solution, in the general case, but I'm
sure the development team will be able to put together something
that's more appropriate. The proposed solution does incorporate
the use of snprintf(), which may not be available on all systems.
What follows is a patch, as I have applied to my own systems (Linux
and OSF with external snprintf library) to work around this problem,
by placing the credentials cache in the user's home directory:

--- /local/pkg/kerberos/kerberos-1.2.5/src/lib/krb5/os/ccdefname.c.original Thu Feb 28 12:11:41 2002
+++ /local/pkg/kerberos/kerberos-1.2.5/src/lib/krb5/os/ccdefname.c Mon May 6 15:56:54 2002
@@ -222,9 +222,38 @@

#else
#if !(defined(_MSDOS) || defined(_WIN32))
+#ifndef USE_TMPDIR_CC
+#include <pwd.h>
+#include <sys/types.h>
+#endif
+/*
+ * 2002/05/06 Sylvain Robitaille: In order to prevent denial of service
+ * on multi-user systems, we'll place the credentials cache
+ * in a hidden file in the user's home directory.
+ */
static krb5_error_code get_from_os(char *name_buf, int name_size)
{
+#ifndef USE_TMPDIR_CC
+ struct passwd *pw;
+
+ pw = getpwuid(getuid());
+ if(!pw) {
+ /* Couldn't find user's password file entry? */
+ sprintf(stderr, "ERROR: No password file entry found for uid %d\n",
+ getuid());
+ /*
+ * We need to exit right here, since our return value is
+ * ultimately not sufficiently checked.
+ */
+ exit(-1);
+ }
+ /* Ok, we have a password file entry for this user */
+ /* name_buf comes from a 1024-byte array in krb5_cc_set_default_name(). */
+ snprintf(name_buf, 1024, "FILE:%s/.krb5cc_%d",
+ pw->pw_dir, pw->pw_uid);
+#else
sprintf(name_buf, "FILE:/tmp/krb5cc_%d", getuid());
+#endif
return 0;
}
#endif

From: Sam Hartman <hartmans@MIT.EDU>
To: Sylvain Robitaille <syl@alcor.concordia.ca>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-clients/1104: krb5-clients: potential denial of service on
multi-user systems
Date: Fri, 10 May 2002 14:29:28 -0400

We don't actually consider the DOS potential with kinit to be a
problem, and it is certainly not one we are able to fix even if we
wanted to. The user can choose to set the KRB5CCNAME environment
variable to use an alternate cache location if desired. In practice,
in most settings, we just don't see users trying to be malicious in
this way, and it is easy to protect against for applications where it
is important.


We will not accept a patch to store the credentials in the user's home
directory; in environments where the home directory is in AFS or NFS,
this creates a significant security hole. Since Kerberos tends to
lend itself to use in distributed situations, these environments are
quite common.


We would certainly consider it a serious bug if there is a way to
exploit such a symlink to overwrite some file, although as your test
case seems to suggest that does not happen.

I consider it an open question as to whether it is a bug that
applications like telnetd and klogind use a predictable cache name for
forwarded credentials. I would be interested in any opinion you have
on this issue.

From: Sylvain Robitaille <syl@alcor.concordia.ca>
To: Sam Hartman <hartmans@mit.edu>
Cc: krb5-bugs@mit.edu
Subject: Re: krb5-clients/1104: krb5-clients: potential denial of service on
multi-user systems
Date: Fri, 10 May 2002 15:57:29 -0400 (EDT)

On Fri, 10 May 2002, Sam Hartman wrote:


Hrmmm... On the surface I find it hard to agree with you (though I agree
that fixing this is far from a trivial problem), but I do understand
and respect your points.


Yes, but I think in my case (with locally mounted home directory), I'll
carry on with my mod to write into the user's home directory. If we
find ourselves in a situation with network-mounted home directories,
(which is certainly not unlikely), I'll have to look for a different
solution.


Sure, and I've seen many dangerous street intersections where the
authorities knew it was just a matter of time before people got killed,
yet they didn't put up street lights until the inevitable finally did
happen. I certainly don't agree with this reasoning. I think you've
been lucky, is all. :-(


By the environment variable, I take it you mean.


That's obviously a very good point, and one which I'd missed. I agree
that in this case, it's necessary to keep the credentials cache local.

The trick, then, is how to make it difficult for one user to prevent
another user from creating the credentials cache. I suppose it would
be possible to just write a script that periodically scans the /tmp
directory looking for (and reporting to the sysadmin) "incorrectly owned"
credentials cache files.


Understood.


No. I definitely tested for that, on both Linux and DEC-Unix 4.0, and
found in both cases that it still fails if the link target exists and is
writable by the user calling kinit.


Well, I can't see how they could be made to work otherwise, since
they're ultimately used by yet other (client) applications (unless I've
completely misunderstood something -- well, I suppose with forwarded
credentials, an environment variable could be set by the daemon so the
clients will find the file; in that case the daemon could loop around
trying different filenames if the file name it first tries already
exists).

I suppose that what I'm considering to be a "bug" (if it can be called
that at this point) is that these predictably named files are stored
in a directory which other users are able to write to (and therefore
potentially prevent a user from being able to authenticate to the KDC).

Obviously I'm going to have to give this some more thought. Thank you
for pointing out the glaring oversight with my suggestion. If I come up
with an improvement, I'll be sure to submit a new report...

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------



From: Sam Hartman <hartmans@MIT.EDU>
To: Sylvain Robitaille <syl@alcor.concordia.ca>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-clients/1104: krb5-clients: potential denial of service on
multi-user systems
Date: Fri, 10 May 2002 16:34:12 -0400

If you consider this type of problem to be within your threat model,
then you should look into per-user temporary directories. For systems
that support PAM, there is the pam_tmpdir module which attempts to
create a per-user temporary directory while still root to avoid this
and other attacks.

You could probably adopt a similar solution on non-PAM systems.


From: Sylvain Robitaille <syl@alcor.concordia.ca>
To: Sam Hartman <hartmans@mit.edu>
Cc: krb5-bugs@mit.edu
Subject: Re: krb5-clients/1104: krb5-clients: potential denial of service on
multi-user systems
Date: Fri, 10 May 2002 16:37:59 -0400 (EDT)

On Fri, 10 May 2002, Sam Hartman wrote:


It's worth thinking about. Thanks.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------