-----BEGIN PGP SIGNED MESSAGE----- MIT krb5 Security Advisory 2003-004 [updated] 2003-03-18 [updated; revision history at end] Original Release Date: 2003-03-17 Topic: Cryptographic weaknesses in Kerberos v4 protocol Severity: CRITICAL SUMMARY ======= A cryptographic weakness in version 4 of the Kerberos protocol allows an attacker to use a chosen-plaintext attack to impersonate any principal in a realm. Additional cryptographic weaknesses in the krb4 implementation included in the MIT krb5 distribution permit the use of cut-and-paste attacks to fabricate krb4 tickets for unauthorized client principals if triple-DES keys are used to key krb4 services. These attacks can subvert a site's entire Kerberos authentication infrastructure. Kerberos version 5 does not contain this cryptographic vulnerability. Sites are not vulnerable if they have Kerberos v4 completely disabled, including the disabling of any krb5 to krb4 translation services. IMPACT ====== * An attacker controlling a krb4 shared cross-realm key can impersonate any principal in the remote realm to any service in the remote realm. This can lead to root-level compromise of a KDC, along with compromise of any hosts that rely on authentication provided by that KDC. * This attack may be performed against cross-realm principals, thus allowing an attacker to hop realms and compromise any realm that transitively shares a cross-realm key with the attacker's local realm. * Related, but more difficult attacks may be possible without requiring the control of a shared cross-realm key. At the very least, an attacker capable of creating arbitrary principal names in the target realm may be able to perform the attack. * An attacker may impersonate any principal to a service keyed with triple-DES krb4 keys, given the ability to capture network traffic containing tickets for the target client principal. * A leak has occurred of an unpublished paper containing enough details about the vulnerability that an attacker familiar with the krb4 protocol can easily construct an exploit. No exploit is known to be circulating at this time, though. AFFECTED SOFTWARE ================= * These are protocol vulnerabilities; ALL implementations of vulnerable functionality are vulnerable. * All implementations of the Kerberos version 4 Key Distribution Center that allow cross-realm authentication are vulnerable. * All implementations of the Kerberos version 5 Key Distribution Center that also implement a KDC for the Kerberos version 4 protocol and use the same keys for version 4 and version 5 are vulnerable. * MIT implementations of krb5 that include support for triple-DES keys in krb4 are vulnerable. FIX === * These are PROTOCOL vulnerabilities; fixes inherently involve restricting the functionality of the protocol. * If you are using the implementation of krb4 contained in the MIT krb5, apply the patch kit, which is available at http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patchkit.tar.gz The detached PGP signature of the patch kit is available at http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patchkit.sig * Release 1.3 of MIT krb5 will include a fix. The fix has also been committed to our development source tree. * If you are using MIT krb5, and do not require krb4 functionality, you should completely disable the krb4 functionality of the KDC by restarting the KDC with the "-4 none" or the "-4 disable" option. You should also cease running the krb524d. Ceasing use of krb4-salted keys is not sufficient. * If you are running MIT release krb5-1.2.6 or later, and you are unable to patch your production code, setting the DISALLOW_ALL_TIX or the DISALLOW_SVR attributes on all cross-realm principals should disable cross-realm authentication without losing key information. This will, of course, cause loss of krb5 cross-realm functionality. Note that the functionality of these principal attributes has not been extensively tested. * If using the Kerberos v4 implementation contained in MIT krb5, and you are unable to patch your production systems, cease use of triple-DES keys for Kerberos v4 services by downgrading to single-DES keys for all services that accept krb4 authentication. Note that you must also separately address the existence of krb4 cross-realm keys. * If using a non-MIT implementation of krb4, disable all krb4 cross-realm functionality, both in KDC implementations and in any krb524d implementations. * A possible workaround is to randomize or delete all cross-realm keys. This should be considered to be a last resort, as re-establishing cross-realm keys can be time-consuming, and krb5 cross-realm functionality will be lost. * The following text describes the patch kit for the MIT krb5 implementation. PATCH KIT DESCRIPTION ===================== ** FLAG DAY REQUIRED ** One of the things we decided to do (and must do for security reasons) was drop support for the 3DES krb4 TGTs. Unfortunately the current code will only accept 3DES TGTs if it issues 3DES TGTs. Since the new code issues only DES TGTs, the old code will not understand its v4 TGTs if the site has a 3DES key available for the krbtgt principal. The new code will understand and accept both DES and 3DES v4 TGTs. So, the easiest upgrade option is to deploy the code on all KDCs at once, being sure to deploy it on the master KDC last. Under this scenario, a brief window exists where slaves may be able to issue tickets that the master will not understand. However, the slaves will understand tickets issued by the master throughout the upgrade. An alternate and more annoying upgrade strategy exists. At least one max TGT life time before the upgrade, the TGT key can be changed to be a single-des key. Since we support adding a new TGT key while preserving the old one, this does not create an interruption in service. Since no 3DES key is available then both the old and new code will issue and accept DES v4 TGTs. After the upgrade, the TGT key can again be rekeyed to add 3DES keys. This does require two TGT key changes and creates a window where DES is used for the v5 TGT, but creates no window in which slaves will issue TGTs the master cannot accept. * What the patch does ===================== 1) Kerberos 4 cross-realm authentication is disabled by default. A "-X" switch is added to both krb524d and krb5kdc to enable v4 cross-realm. This switch logs a note that a security hole has been opened in the KDC log. We said while designing the patch, that we were going to try to allow per-realm configuration; because of a design problem in the kadm5 library, we could not do this without bumping the ABI version of that library. We are unwilling to bump an ABI version in a security patch release to get that feature, so the configuration of v4 cross-realm is a global switch. 2) Code responsible for v5 TGTs has been changed to require that the enctype of the ticket service key be the same as the enctype that would currently be issued for that kvno. This means that even if a service has multiple keys, you cannot use a weak key to fake the KDC into accepting tickets for that service. If you have a non-DES TGT key, this separates keys used for v4 and v5. We actually relax this requirement for cross-realm TGT keys (which in the new code are only used for v5) because we cannot guarantee other Kerberos implementations will choose keys the same way. 3) We no longer issue 3DES v4 tickets either in the KDC or krb524d. We add code to accept either DES or 3DES tickets for v4. None of the attacks discovered so far can be implemented given a KDC that accepts but does not issue 3DES tickets, so we believe that leaving this functionality in as compatibility for a version or two is reasonable. Note however that the attacks described do allow successful attackers to print future tickets, so sites probably want to rekey important keys after installing this update. Note also that even if issuance of 3DES v4 tickets has been disabled, outstanding tickets may be used to perform the 3DES cut-and-paste attack. REFERENCES ========== This announcement and related security advisories may be found on the MIT Kerberos security advisory page at: http://web.mit.edu/kerberos/www/advisories/index.html The main MIT Kerberos web page is at: http://web.mit.edu/kerberos/www/index.html [note that these CERT Vulnerability Notes have not yet been published] CERT VU#623217 http://www.kb.cert.org/vuls/id/623217 CERT VU#442569 http://www.kb.cert.org/vuls/id/442569 ACKNOWLEDGMENTS =============== This advisory was written by Sam Hartman and Tom Yu. Ken Raeburn participated in the analysis of the cryptographic vulnerabilities. Steve Bellovin provided some hints that led us to discover this vulnerability. Sam Hartman developed the patch kit for MIT krb5 implementations. CONTACT ======= For more information, contact Sam Hartman , or Marshall Vale . DETAILS ======= * Abstract ========== Several cryptographic vulnerabilities exist in the basic Kerberos Version 4 protocol that could allow an attacker to impersonate any user in a Kerberos realm and gain any privilege authorized through that Kerberos realm. Knowledge of the key shared between two realms for Kerberos 4 cross-realm authentication or the ability to create arbitrary principals in a realm is sufficient to print any ticket in the realm. As an example, knowing krbtgt.ZONE.MIT.EDU@ATHENA.MIT.EDU is sufficient to print an Athena TGT for any Athena realm client. Additional vulnerabilities in a MIT extension to use triple DES keys for Kerberos 4 tickets may allow attackers who can passively observer the network to construct tickets for some users if certain alignment constraints are met. The Kerberos 5 protocol is not vulnerable to this issue. However, implementations that implement both Kerberos 4 and Kerberos 5 tend to use the same keys for both protocols. As a result, the Kerberos 4 vulnerabilities can be used to compromise Kerberos 5 services at sites using these implementations. * Brief Problem Description =========================== Kerberos version 4 tickets include neither a cryptographic hash of the encrypted data, random padding, nor a random initial vector. As such, if an attacker can cause the right text to be encrypted in a Kerberos service key, then the attacker can fabricate a ticket. Normally an attacker does not control much of the text in the ticket so this cryptographic weakness is hard to exploit. The initial portion of a Kerberos 4 ticket is a one-byte flags field (either 0 or 1) followed by the client name. Since all of this initial text is constant, the beginning of a ticket for a given client/service will be the same. An attacker thus knows the encryption of the initial plaintext in the service key. If an attacker can control client principals whose names he chooses, then he can get the encryption of these plaintext values in the service key. As a result of concerns about single DES weaknesses, MIT implemented support for Kerberos 4 tickets encrypted in triple DES service keys. This support shares all the cryptographic weaknesses of single DES Kerberos 4. In addition, since it uses CBC mode rather than PCBC mode, it introduces new weaknesses not found in other Kerberos 4 implementations. When certain alignment constraints are met, it is possible to splice two tickets together, allowing an attacker to get a ticket with a known session key for a client without knowing that client's long term key. This attack does require sniffing a ticket for that client. We do not believe the password changing service is vulnerable to the single DES attacks as the KDC will never issue password changing tickets in an appl request. It is probably vulnerable to the triple DES splicing attacks. * Specific Vulnerabilities ========================== 1) ECB Oracle for Single DES By controlling principals of an attackers choice, an attacker can encrypt arbitrary plaintext in a single DES service key. 2) ECB Oracle for Triple DES By controlling principals of an an attacker's choice, an attacker can encrypt arbitrary plaintext in a triple DES service key. 3) PCBC First Block It turns out that being able to encrypt arbitrary plaintext is not quite enough to construct a ticket for a single DES service key. You also need to be able to construct the first block of the ticket; you don't know what plaintext to use because the IV for the first block is the long-term service key. However since the only thing in the first block of the ticket is the first seven bytes of the client, controlling a principal with the same first seven bytes as the principal being attacked is sufficient to get the first block. As a practical matter, principals whose principal and instance components fit within six bytes (including trailing nulls) may be harder to attack. 4) Cross Realm If realms A and B share a cross-realm key and the attacker knows that key or can get arbitrary plaintext encrypted in that key, then the attacker may get A to issue tickets for any principal claiming to be in realm B and vice versa. This is sufficient to meet conditions of vulnerabilities (1) and (2) above and to encrypt arbitrary plaintext in the service keys of realm A and B. 5) Kerberos 4 Ticket Printing The conditions of (2) above are sufficient to print arbitrary tickets in a triple DES service key. The conditions of (1) and (3) are sufficient to print any ticket in a single DES service key. 6) Kerberos 5 Ticket Printing The conditions of (1) above are sufficient to construct a des-cbc-md4 or des-cbc-md5 Kerberos 5 ticket if the KDC uses the same DES key for v4 and v5. While the Kerberos 5 ticket does have a confounder and checksum, the checksum is not keyed and thus the confounder and checksum can be fabricated by an attacker. We believe that des-cbc-crc is safe unless you can contain a ciphertext block and a corresponding plaintext block. However, most Kerberos implementations will allow des-cbc-md5 to be used even if des-cbc-crc is normally used. We are not aware of any vulnerabilities in des3-hmac-sha1-kd or rc4-hmac-md5. 7) Ticket Splicing Attack A Kerberos 4 ticket contains an eight-byte session key. If client principal names are chosen carefully then this session key will line up with a DES block boundary. For triple DES service keys this creates an opportunity for an attack. Consider the case where an attacker has obtained a ticket t1 with a known session key K and has sniffed a ticket t2 with unknown session key for the same service. The attacker can create a new valid ticket t2' by replacing the part of t2 starting with the session key block with the session key from t1. This new ticket will have a session key K XOR-ed with the ciphertext blocks proceeding the session key in t1 and t2. In other words, if triple DES service keys are used, client principals with the wrong name lengths are inherently vulnerable to sniffing. 8) Realm Hopping Kerberos 4 does not normally support multi-hop cross-realm authentication. However cross-realm tickets are just normal service keys; points (1), (2) and (3) are sufficient to satisfy the conditions of point (4) for a service key. That is, an attacker can hop through realms, exploiting these vulnerabilities against any realm that is in the transitive closure of the initial realm. Anyone who shares keys with ATHENA.MIT.EDU now trusts ZONE.MIT.EDU. 9) Krb 524 Does Not Help Traditionally realms desiring higher security but still wishing to have some Kerberos 4 services have disabled KDC support for V4 and used krb524d to issue only the services that are needed. These vulnerabilities work as well against any service key that the krb524d knows as they do against service keys in a v4 KDC. Of course a fabricated krb5 ticket can be converted to Kerberos 4 using krb524d. * Potential Solutions ===================== 1) V4 Cross Realm Considered Harmful Kerberos implementations should gain an option to disable Kerberos 4 cross-realm authentication both in the KDC and in any implementations of the krb524 protocol. This configuration should be the default. 2) Application Migration Application vendors and sites should migrate from Kerberos version 4 to Kerberos version 5. The OpenAFS community has introduced features that allow Kerberos 5 to be used for AFS in OpenAFS 1.2.8. Patches are available to add Kerberos 5 support to OpenSSH. Several other implementations of the SSH protocol also support Kerberos 5. Applications such as IMAP, POP and LDAP already support Kerberos 5. 3) TGT Key Separation One motivation for the V4 triple DES support is that if a single DES key exists for the TGT principal then an attacker can attack that key both for v4 and v5 tickets. Kerberos implementations should gain support for a DES TGT key that is used for v4 requests but not v5 requests. 4) Remove Triple DES Kerberos 4 Support The cut and paste attack is a critical failure in MIT's attempt at Kerberos 4 Triple DES. Even without cross-realm authentication, this can be exploited in real-world situations. As such the support for 3DES service keys should be disabled. REVISION HISTORY ================ 2003-03-15 A draft version of this text was leaked to the full-disclosure list by unknown persons. 2003-03-17 original release 2003-03-18 Clarified fixes. Updated patch kit to fix 1.2.7 patch (incorect versions had been used to generate the patch). Updated patch kit to fix 1.3 patch (previously prevented kadmind from starting). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iQCVAwUBPnfMiabDgE/zdoE9AQGy9wP+OU4z+pjtreXd3XZWiBfADBR2RTpwzJLk 0D5C7e12P8gWjl2EavVJDCNomxburaeK456H4QmPRaxzR0osoE2pvz8lp+LEl8oA jjkuszDQ6mw4tQ6CthybuxSBofoGs9x6q6vID2XuTIRnyKLkwet/RLNq/ujzhP9Q 2KB5cO1/yxI= =p8EY -----END PGP SIGNATURE-----