[UNIX] Cryptographic Weaknesses in Kerberos v4 Protocol

From: support@securiteam.com
Date: 03/17/03

  • Next message: support@securiteam.com: "[EXPL] Exploit Released for the Intel PXE Buffer Overflow" 
    From: support@securiteam.com
To: list@securiteam.com
Date: 17 Mar 2003 19:50:04 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    In the US?

    Contact Beyond Security at our new California office
    housewarming rates on automated network vulnerability
    scanning. We also welcome ISPs and other resellers!

    Please contact us at: 323-882-8286 or ussales@beyondsecurity.com
    - - - - - - - - -

      Cryptographic Weaknesses in Kerberos v4 Protocol
    ------------------------------------------------------------------------

    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.

    DETAILS

    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.

    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.

    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>
    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>
    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 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.

     * If using a different implementation of krb4, disable all krb4
    cross-realm functionality, both in KDC implementations and in any krb524d
    implementations.

     * A possible workaround is to randomize all cross-realm keys. This should
    be considered 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:
    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.

    Therefore, 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 lifetime 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.

    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.

    ADDITIONAL INFORMATION

    The original advisory can be downloaded from:
     <http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt>
    http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt

    For more information, contact <mailto:hartmans@mit.edu> Sam Hartman, or
    <mailto:mjv@mit.edu> Marshall Vale.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: support@securiteam.com: "[EXPL] Exploit Released for the Intel PXE Buffer Overflow"