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 ; 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 ; 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 Reply-To: Sylvain Robitaille To: krb5-bugs@mit.edu Cc: Sylvain Robitaille Subject: krb5-clients: potential denial of service on multi-user systems X-Send-Pr-Version: 3.99 >Number: 1104 >Category: krb5-clients >Synopsis: potential denial of service on multi-user systems >Confidential: no >Severity: serious >Priority: medium >Responsible: krb5-unassigned >State: open >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Wed May 8 15:55:00 EDT 2002 >Last-Modified: Fri May 10 16:39:00 EDT 2002 >Originator: Sylvain Robitaille >Organization: Concordia University, Montreal, Quebec, Canada ---------------------------------------------------------------------- Sylvain Robitaille syl@alcor.concordia.ca Systems Manager Concordia University Instructional & Information Technology Montreal, Quebec, Canada ---------------------------------------------------------------------- >Release: krb5-1.2.5 >Environment: 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 >Description: 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. >How-To-Repeat: 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 >Fix: 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 +#include +#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 >Audit-Trail: From: Sam Hartman To: Sylvain Robitaille 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 To: Sam Hartman 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: > 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. 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. > The user can choose to set the KRB5CCNAME environment > variable to use an alternate cache location if desired. 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. > In practice, in most settings, we just don't see users trying to be > malicious in this way, 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. :-( > and it is easy to protect against for applications where it is > important. By the environment variable, I take it you mean. > 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. 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. > Since Kerberos tends to lend itself to use in distributed situations, > these environments are quite common. Understood. > 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. 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. > 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. 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 To: Sylvain Robitaille 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 To: Sam Hartman 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: > If you consider this type of problem to be within your threat model, > then you should look into per-user temporary directories. It's worth thinking about. Thanks. -- ---------------------------------------------------------------------- Sylvain Robitaille syl@alcor.concordia.ca Systems analyst Concordia University Instructional & Information Technology Montreal, Quebec, Canada ---------------------------------------------------------------------- >Unformatted: