Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2003.0205 -- MIT krb5 Security Advisories 2003-004 and 2003-005
Cryptographic weaknesses in Kerberos v4 protocol and Buffer overrun and
underrun in principal name handling
25 March 2003
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: krb5
Vendor: MIT
Operating System: Linux
UNIX
Impact: Root Compromise
Denial of Service
Access Required: Remote
Comment: Please note, this External Security Bulletin contains two MIT
advisories.
The first references protocol vulnerabilities in version 4 of
the Kerberos protocol. The second references vulnerabilities in
krb5 all released versions though 1.2.7 and 1.3-alpha1.
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
MIT krb5 Security Advisory 2003-004
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 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 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 <hartmans@mit.edu>, or
Marshall Vale <mjv@mit.edu>.
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
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (SunOS)
iQCVAwUBPnWBm6bDgE/zdoE9AQEqywP/djVs+A4aTwJUTXzUHno5kGz1qEEzeF6v
Uda7/NZyswe7Prc4J8vP9NEUSb/aETLcWuUmSmzViy0yCl4LwiVRPwtQNnTkjHbb
aWp1xqbEjGmXlEpsf2y5vylbGBC0fBImf38UD8mw0qmjByLJ9+MQGUX0ggIgN72H
GtnGXq1m+Jw=
=ws8J
- -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MIT krb5 Security Advisory 2003-005
Original release date: 2003-03-19
Last update: 2003-03-20
Topic: Buffer overrun and underrun in principal name handling
Severity: SERIOUS
SUMMARY
=======
Buffer overrun and underrun problems exist in Kerberos principal name
handling in unusual cases, such as names with zero components, names
with one empty component, or host-based service principal names with
no host name component.
IMPACT
======
* Corruption of malloc pool, probably leading to program crash.
+ The KDC may be vulnerable.
+ Depending on the malloc implementation and platform, it may be
possible to build more serious exploits on this.
* Reference to data just past the end of an array in the KDC, for
comparison against certain fixed data. May result in crashing the
KDC.
AFFECTED SOFTWARE
=================
MIT Kerberos 5, all released versions though 1.2.7 and 1.3-alpha1.
FIX
===
The following patches should fix the most urgent aspects of the
problems in the 1.2.7 release. If these patches do not apply cleanly
to 1.2.6 and earlier versions, the corresponding changes should be
fairly straightforward. The patch to krb5.hin should change any
missed overrun cases in this area into null pointer dereferences,
which will be more likely to crash the program instead of referencing
arbitrary data.
Patch: http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-005-patch.txt
Patch PGP signature: http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-005-patch.txt.asc
The problem exists in other parts of the code as well, but should only
result in crashing application servers when the realm has been
misconfigured to use broken service names, or crashing application
clients when they are supplied broken principal names.
REFERENCES
==========
CVE CAN-2003-0082
Buffer underrun
CVE CAN-2003-0072
Array overrun -- only the portions that appeared to affect a server
with no strange realm configurations were included here.
ACKNOWLEDGMENTS
===============
Thanks to Nalin Dahyabhai of Red Hat for bringing the problems to our
attention.
CONTACT
=======
For more information, contact Ken Raeburn <raeburn@mit.edu>, Sam
Hartman <hartmans@mit.edu>, or Marshall Vale <mjv@mit.edu>.
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
REVISION HISTORY
================
2003-03-19 original release
2003-03-19 moved patch to separate file with separate signature
2003-03-20 added CVE identification
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+ejUuUqOaDMQ+e5gRAm/nAJ9jZg/hMXnBk9WYG1qUOtH4hO9IowCg3vVR
XUH3AHu/7KLAW3tvHlHeBGk=
=qzhr
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to use any or all of this information is
the responsibility of each user or organisation, and should be done so in
accordance with site policies and procedures.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/render.html?cid=1980
If you believe that your system has been compromised, contact AusCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business
hours which are GMT+10:00 (AEST). On call after hours
for member emergencies only.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: http://www.auscert.org.au/render.html?it=1967
iQCVAwUBPoBEHCh9+71yA2DNAQGd5QP/aRUXoGczjothFVHPbLDYugPCj5CF883m
qXxD6jwTPcv4i0M1eoQOhFsHr4SDqm97pLn5zxnxwCEm9R8EzoSdnJe/uBGKh+/C
klnr1jnCXRfh/pjtmDoH76xv1IfqDNQTqbPVCXFf1Ld2hLxv5MDDEZZm8PvapNI1
dmtjIIc3x+E=
=QDMX
-----END PGP SIGNATURE-----