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: 4167 From basch@lehman.com Wed Dec 18 23:52:09 1996 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id XAA01367 for ; Wed, 18 Dec 1996 23:52:08 -0500 Received: from lehman.Lehman.COM by MIT.EDU with SMTP id AA24456; Wed, 18 Dec 96 23:52:07 EST Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id XAA05705 for ; Wed, 18 Dec 1996 23:52:03 -0500 Received: from relay.messaging-svcs2.lehman.com(146.127.39.20) by lehman via smap (V1.3) id tmp005703; Wed Dec 18 23:52:01 1996 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA17750; Wed, 18 Dec 96 23:52:00 EST Received: from badger.lehman.com by kublai.lehman.com (4.1/Lehman Bros. V1.6) id AA11620; Wed, 18 Dec 96 23:51:58 EST Received: by badger.lehman.com (SMI-8.6/Lehman Bros. V1.5) id XAA18450; Wed, 18 Dec 1996 23:51:58 -0500 Message-Id: <199612190451.XAA18450@badger.lehman.com> Date: Wed, 18 Dec 1996 23:51:58 -0500 From: "Richard Basch" To: krb5-bugs@MIT.EDU Subject: possible ksu hole >Number: 306 >Category: krb5-clients >Synopsis: possible ksu hole >Confidential: yes >Severity: serious >Priority: high >Responsible: tlyu >State: closed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Wed Dec 18 23:53:00 EST 1996 >Last-Modified: Wed Feb 04 21:51:18 EST 1998 >Originator: >Organization: >Release: >Environment: >Description: Note: I have not tested the following in awhile, but the code path looks like the condition still exists... Problem: If a user obtains credentials, with kinit, and then accesses the local host such that they have a credential for the local machine (perhaps login acquires one... it doesn't matter...), and then the credentials expire, ksu should prompt for a password. However, ksu blindly trusts the expired credentials. Looking at krb_auth_su.c, krb5_auth_check() will check the credential expiration time. However, the function will first call krb5_fast_auth to see if there are existing credentials that decode properly and if there are, it will return success. Using that code path, krb5_check_exp() is not called, thereby permitting expired credentials to function. Richard Basch Sr. Developer/Analyst, DSO URL: http://web.mit.edu/basch/www/home.html Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu 101 Hudson St., 38th Floor Fax: +1-201-524-5828 Jersey City, NJ 07302-3988 Voice: +1-201-524-5049 >How-To-Repeat: >Fix: >Audit-Trail: Responsible-Changed-From-To: gnats-admin->krb5-unassigned Responsible-Changed-By: tlyu Responsible-Changed-When: Sat Jan 25 21:16:10 1997 Responsible-Changed-Why: Refiled From: Tom Yu To: Unassigned Problem Report Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-clients/306: possible ksu hole Date: Sat, 25 Jan 1997 21:33:32 -0500 `Tom Yu' made changes to this PR. *** /tmp/gnatsa00141 Sat Jan 25 21:32:46 1997 --- /tmp/gnatsb00141 Sat Jan 25 21:33:15 1997 *************** *** 15,25 **** Date: Wed, 18 Dec 1996 23:51:58 -0500 From: "Richard Basch" To: krb5-bugs@MIT.EDU ! Subject: ksu >Number: 306 >Category: krb5-clients ! >Synopsis: ksu >Confidential: yes >Severity: serious >Priority: high --- 15,25 ---- Date: Wed, 18 Dec 1996 23:51:58 -0500 From: "Richard Basch" To: krb5-bugs@MIT.EDU ! Subject: possible ksu hole >Number: 306 >Category: krb5-clients ! >Synopsis: possible ksu hole >Confidential: yes >Severity: serious >Priority: high Responsible-Changed-From-To: krb5-unassigned->tlyu Responsible-Changed-By: tlyu Responsible-Changed-When: Wed Feb 4 21:50:40 1998 Responsible-Changed-Why: State-Changed-From-To: open-closed State-Changed-By: tlyu State-Changed-When: Wed Feb 4 21:50:47 1998 State-Changed-Why: Ok we have a duplicate in 545, which also includes what seems like a reasonable patch. >Unformatted: