[UNIX] Cryptographic Weaknesses in Kerberos v4 Protocol
From: email@example.com To: firstname.lastname@example.org 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 email@example.com
- - - - - - - - -
Cryptographic Weaknesses in Kerberos v4 Protocol
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.
* 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.
* 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.
* 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
The detached PGP signature of the patch kit is available at
* 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
* 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
* 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
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
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
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
Sam Hartman developed the patch kit for MIT krb5 implementations.
The original advisory can be downloaded from:
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: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
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.