[OpenAFS-devel] FW: MITKRB5-SA-2003-004: Cryptographic weaknesses in Kerberos v4 protocol

[Neulinger, Nathan]

The reason for my inquiry about the krb524 migration...=20



------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Tom Yu [mailto:tlyu@mit.edu]=20
> Sent: Monday, March 17, 2003 2:21 AM
> To: kerberos-announce@mit.edu
> Cc: bugtraq@securityfocus.com
> Subject: MITKRB5-SA-2003-004: Cryptographic weaknesses in=20
> Kerberos v4 protocol
>=20
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
>=20
>                  MIT krb5 Security Advisory 2003-004
>=20
> 2003-03-17
>=20
> Topic: Cryptographic weaknesses in Kerberos v4 protocol
>=20
> Severity: CRITICAL
>=20
> SUMMARY
> =3D=3D=3D=3D=3D=3D=3D
>=20
> 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.
>=20
> 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.
>=20
> IMPACT
> =3D=3D=3D=3D=3D=3D
>=20
> * 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.
>=20
> * 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.
>=20
> * 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.
>=20
> * 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.
>=20
> * 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.
>=20
> AFFECTED SOFTWARE
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> * These are protocol vulnerabilities; ALL implementations of
>   vulnerable functionality are vulnerable.
>=20
> * All implementations of the Kerberos version 4 Key Distribution
>   Center that allow cross-realm authentication are vulnerable.
>=20
> * 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.
>=20
> * MIT implementations of krb5 that include support for triple-DES keys
>   in krb4 are vulnerable.
>=20
> FIX
> =3D=3D=3D
>=20
> * These are PROTOCOL vulnerabilities; fixes inherently involve
>   restricting the functionality of the protocol.
>=20
> * If you are using the implementation of krb4 contained in the MIT
>   krb5, apply the patch kit, which is available at
>=20
>  =20
> http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patch
> kit.tar.gz
>=20
>   The detached PGP signature of the patch kit is available at
>=20
>  =20
> http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patchkit.sig
>=20
> * Release 1.3 of MIT krb5 will include a fix.  The fix has also been
>   committed to our development source tree.
>=20
> * 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.
>=20
> * 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.
>=20
> * If using a different implementation of krb4, disable all krb4
>   cross-realm functionality, both in KDC implementations and in any
>   krb524d implementations.
>=20
> * A possible workaround is to randomize 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.
>=20
> * The following text describes the patch kit for the MIT krb5
>   implementation.
>=20
> PATCH KIT DESCRIPTION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> ** FLAG DAY REQUIRED **
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> * What the patch does
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> REFERENCES
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> This announcement and related security advisories may be found on the
> MIT Kerberos security advisory page at:
>=20
>         http://web.mit.edu/kerberos/www/advisories/index.html
>=20
> The main MIT Kerberos web page is at:
>=20
>         http://web.mit.edu/kerberos/www/index.html
>=20
> [note that these CERT Vulnerability Notes have not yet been published]
>=20
> CERT VU#623217
>=20
>         http://www.kb.cert.org/vuls/id/623217
>=20
> CERT VU#442569
>=20
>         http://www.kb.cert.org/vuls/id/442569
>=20
> ACKNOWLEDGMENTS
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> This advisory was written by Sam Hartman and Tom Yu.  Ken Raeburn
> participated in the analysis of the cryptographic vulnerabilities.
>=20
> Steve Bellovin provided some hints that led us to discover this
> vulnerability.
>=20
> Sam Hartman developed the patch kit for MIT krb5 implementations.
>=20
> CONTACT
> =3D=3D=3D=3D=3D=3D=3D
>=20
> For more information, contact Sam Hartman <hartmans@mit.edu>, or
> Marshall Vale <mjv@mit.edu>.
>=20
> DETAILS
> =3D=3D=3D=3D=3D=3D=3D
>=20
> * Abstract
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 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.
>=20
> 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.
>=20
> * Brief Problem Description
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> * Specific Vulnerabilities
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
>=20
> 1) ECB Oracle for Single DES
>=20
>     By controlling principals of an attackers choice, an attacker can
>     encrypt arbitrary plaintext in a single DES service key.
>=20
> 2) ECB Oracle for Triple DES
>=20
>     By controlling principals of an an attacker's choice, an attacker
>     can encrypt arbitrary plaintext in a triple DES service key.
>=20
> 3) PCBC First Block
>=20
>     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.
>=20
> 4) Cross Realm
>=20
>     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.
>=20
> 5) Kerberos 4 Ticket Printing
>=20
>     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.
>=20
> 6) Kerberos 5 Ticket Printing
>=20
>     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.
>=20
> 7) Ticket Splicing Attack
>=20
>     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.
>=20
> 8) Realm Hopping
>=20
>     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.
>=20
> 9) Krb 524 Does Not Help
>=20
>     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.
>=20
> * Potential Solutions
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 1) V4 Cross Realm Considered Harmful
>=20
>     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.
>=20
> 2) Application Migration
>=20
>     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.
>=20
> 3) TGT Key Separation
>=20
>     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.
>=20
> 4) Remove Triple DES Kerberos 4 Support
>=20
>     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.
>=20
> REVISION HISTORY
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 2003-03-15      A draft version of this text was leaked to the
>                 full-disclosure list by unknown persons.
>=20
> 2003-03-17      original release
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (SunOS)
>=20
> iQCVAwUBPnWBm6bDgE/zdoE9AQEqywP/djVs+A4aTwJUTXzUHno5kGz1qEEzeF6v
> Uda7/NZyswe7Prc4J8vP9NEUSb/aETLcWuUmSmzViy0yCl4LwiVRPwtQNnTkjHbb
> aWp1xqbEjGmXlEpsf2y5vylbGBC0fBImf38UD8mw0qmjByLJ9+MQGUX0ggIgN72H
> GtnGXq1m+Jw=3D
> =3Dws8J
> -----END PGP SIGNATURE-----
> _______________________________________________
> kerberos-announce mailing list
> kerberos-announce@mit.edu
> http://mailman.mit.edu/mailman/listinfo/kerberos-announce
> _______________________________________________
> krbdev mailing list             krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>=20