From ppomes@Qualcomm.com Wed Mar 12 13:45:03 1997 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 NAA01820 for ; Wed, 12 Mar 1997 13:44:58 -0500 Received: from zelkova.qualcomm.com by MIT.EDU with SMTP id AA19261; Wed, 12 Mar 97 13:44:55 EST Received: (from ppomes@localhost) by zelkova.qualcomm.com (8.8.5/8.8.5) id KAA05293; Wed, 12 Mar 1997 10:44:53 -0800 (PST) Message-Id: <199703121844.KAA05293@zelkova.qualcomm.com> Date: Wed, 12 Mar 1997 10:44:53 -0800 (PST) From: ppomes@Qualcomm.com Reply-To: ppomes@Qualcomm.com To: krb5-bugs@MIT.EDU Cc: ppomes@Qualcomm.com, tep@sdsc.edu Subject: -randkey isn't random X-Send-Pr-Version: 3.99 >Number: 395 >Category: krb5-admin >Synopsis: addprinc -randkey appears to generate the same key each time >Confidential: no >Severity: non-critical >Priority: low >Responsible: bjaspan >State: closed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Wed Mar 12 13:46:00 EST 1997 >Last-Modified: Mon Mar 17 16:25:58 EST 1997 >Originator: Paul Pomes >Organization: QUALCOMM, Inc. 6455 Lusk Blvd San Diego, CA 92121-2779 >Release: 1.0 >Environment: System: SunOS zelkova 5.5.1 Generic_103640-04 sun4m sparc SUNW,SPARCstation-20 Architecture: sun4 >Description: When a random key is requested with the -randkey argument to addprinc or modprinc, passwd_check() shows the same password each time. This may not be a problem if there is subsequent randomization, however if there isn't then this is a serious bug. It makes many krb5.keytab file keys guessable. >How-To-Repeat: dbx kadmin.local (dbx) stop in passwd_check (2) stop in passwd_check (dbx) run Running: kadmin.local (process id 5151) kadmin.local: addprinc -randkey fubar stopped in passwd_check at line 49 in file "/usr/local/src/security/kerberos/krb5-1.0/src/lib/kadm5/srv/server_misc.c" 49 int nupper = 0, (dbx) print password [ the eight-bit characters were stripped to 7 in the cut-and-paste ] password = 0x3cd00 "^A^B^C^D^E^F^G^H^I\n^K^L^M^N^O^P^Q^R^S^T^U^V^W^X^Y^Z^[^\^]^^^_ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~^? !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~" (dbx) cont [ A check is also made to FascistCheck() from CrackLib v2.5 ] add_principal: Password is in the password dictionary while creating "fubar@GLOBALSTAR.COM". kadmin.local: addprinc -randkey fubar stopped in passwd_check at line 49 in file "/usr/local/src/security/kerberos/krb5-1.0/src/lib/kadm5/srv/server_misc.c" 49 int nupper = 0, (dbx) print password password = 0x3cd00 "^A^B^C^D^E^F^G^H^I\n^K^L^M^N^O^P^Q^R^S^T^U^V^W^X^Y^Z^[^\^]^^^_ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~^? !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~" (dbx) >Fix: Not investigated yet. >Audit-Trail: From: "Barry Jaspan" To: ppomes@Qualcomm.com Cc: krb5-bugs@MIT.EDU, ppomes@Qualcomm.com, tep@sdsc.edu Subject: Re: krb5-admin/395: addprinc -randkey appears to generate the same key each time Date: Wed, 12 Mar 1997 19:19:07 GMT You can relax; there is not a serious bug here. To explain: When you create a principal with kadm5_create_principal (which kadmin's add_princ uses), you have to specify a password. If you are going to randomize the principal's key, then of course that password doesn't matter; but you still need to specify one. Therefore, when you call add_principal -randkey, the following sequence of events occurs: 1. Create principal with pw = "\x01\x02...\xff" and with DISALLOW_ALL_TIX set. 2. Randomize the principal's key. 3. Modify the principal to unset DISALLOW_ALL_TIX. In step 1, passwd_check() is called with the dummy password, which is why you saw it containing the same value each time. That password is never used. passwd_check() is never called with a random key, because a random key is not a password. You can verify that keys are being randomized by extracting a principal twice into a keytab and using klist -k -K to show the actual keys. That being said, there are still a couple minor issues to resolve: a. You said "the -randkey argument to ... modprinc". modprinc never modifies principal keys, so it does not take the -randkey argument. If it does not actually generate a usage message when one is supplied, though, that is a bug that could confuse a user and should be fixed. b. There is actually a specific automated test to make sure that kadm5_randkey_principal really does generate unique keys. However, a quick glance at the Makefile seems to show that it isn't being run. This should be fixed. Before closing this PR I am going to review and verify all the claims I've made above and fix the minor bugs. Barry From: "Barry Jaspan" To: krb5-bugs@MIT.EDU Cc: Subject: Re: krb5-admin/395: addprinc -randkey appears to generate the same key each time] Date: Wed, 12 Mar 1997 19:50:26 GMT ------- Start of forwarded message ------- X-Mailer: exmh version 2.0gamma 1/27/96 To: "Barry Jaspan" Cc: tep@sdsc.edu Subject: Re: krb5-admin/395: addprinc -randkey appears to generate the same key each time From: Paul Pomes Organization: Qualcomm, Inc. X-Url: In-Reply-To: Your message of Wed, 12 Mar 1997 19:19:07 GMT. <199703121919.TAA25026@beeblebrox.MIT.EDU> Date: Wed, 12 Mar 1997 11:49:03 -0800 Sender: ppomes@Qualcomm.com Thanks, I was hoping for just such an explanation. I was confusing modprinc with cpw for -randkey. I was investigating why my initial port of cracklib was failing and it was because of the initial pattern in the dummy password. I've now added a second check that handles the problem. A diff FYI is enclosed. /pbp ==== % cd krb5-1.0/src/lib/kadm5/srv % rcsdiff -c -r1.1 server_misc.c *** server_misc.c 1997/03/11 22:55:52 1.1 --- server_misc.c 1997/03/12 18:59:31 *************** *** 80,85 **** --- 80,90 ---- return KADM5_PASS_Q_CLASS; if((find_word(password) == KADM5_OK)) return KADM5_PASS_Q_DICT; + #ifdef CRACKLIB_DICTPATH + if (!strncmp("\001\002\003\004\005\006\007\008\009\n\010", password, 11) + && FascistCheck(password, CRACKLIB_DICTPATH)) + return KADM5_PASS_Q_DICT; + #endif else { char *cp; int c, n = krb5_princ_size(handle->context, principal); ------- End of forwarded message ------- From: Marc Horowitz To: ppomes@Qualcomm.com Cc: krb5-bugs@MIT.EDU, tep@sdsc.edu Subject: Re: krb5-admin/395: -randkey isn't random Date: 12 Mar 1997 16:44:03 -0500 ppomes@Qualcomm.com writes: >> When a random key is requested with the -randkey argument to addprinc >> or modprinc, passwd_check() shows the same password each time. This >> may not be a problem if there is subsequent randomization, however >> if there isn't then this is a serious bug. It makes many krb5.keytab >> file keys guessable. There is, in fact, subsequent randomization. If you look at kadmin/cli/kadmin.c:kadmin_addprinc(), you will see this series of actions: - a static buffer (dummybuf) is initialized to a constant octet string - if a random key is requested, the principal is created with the octet string as initial password, with ticket granting disabled. - then, after the principal is created, it is randomized - last, ticket granting is enabled again This isn't exactly the most straightforward process, but it is secure. Marc From: "Barry Jaspan" To: ppomes@Qualcomm.com Cc: krb5-bugs@MIT.EDU, ppomes@Qualcomm.com, tep@sdsc.edu Subject: Re: krb5-admin/395: addprinc -randkey appears to generate the same key each time Date: Thu, 13 Mar 1997 01:09:20 GMT I have confirmed my previous analysis. kadmin's modprinc command does not in fact accept the -randkey argument; it prints an error when it is specified. The automated randkey test was not being run, but I've fixed the Makefile. State-Changed-From-To: open-feedback State-Changed-By: tlyu State-Changed-When: Sun Mar 16 02:20:15 1997 State-Changed-Why: Is there any reason this PR should remain open? From: "Barry Jaspan" To: tlyu@MIT.EDU Cc: ppomes@Qualcomm.com Subject: Re: krb5-admin/395: addprinc -randkey appears to generate the same key each time Date: Sun, 16 Mar 1997 11:05:23 -0500 Ummm.. I guess not. I thought there was something else I wanted to do with it, but I cannot remember what. Barry State-Changed-From-To: feedback-closed State-Changed-By: tlyu State-Changed-When: Mon Mar 17 16:24:35 1997 State-Changed-Why: >Unformatted: