SkipNavigation
US-CERT
American Flag
  Vulnerability
Notes
Database

Search Vulnerability Notes

Vulnerability Notes Help Information


 
 View Notes By
  Name

ID Number

CVE Name

Date Public

Date Published

Date Updated

Severity Metric



 Other Documents
  Technical Alerts

Technical Bulletins

Alerts

Security Tips

 

Vulnerability Note VU#623217

Cryptographic weakness in Kerberos Version 4 protocol

Overview

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.

I. Description

The MIT Kerberos Development team has discovered a serious cryptographic flaw in the Kerberos version 4 protocol. This flaw could allow an attacker to compromise the entire affected Kerberos realm.

From the MIT advisory:

    "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."
Because this is a flaw in the Kerberos 4 protocol, all implementations of vulnerable functionality are vulnerable. This includes all implementations of the Kerberos version 4 Key Distribution Center that allow cross-realm authentication and 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.

The Kerberos version 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.

II. Impact

A number of specific impacts can result because of this vulnerability:

  • An attacker controlling a Kerberos version 4 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.
  • In conjunction with VU#442569, an attacker may impersonate any principal to a service keyed with triple-DES Kerberos version 4 keys, given the ability to capture network traffic containing tickets for the target client principal.

    III. Solution

    Apply a patch from the vendor


The MIT Kerberos team has released MIT krb5 Security Advisory 2003-004 regarding this vulnerability. Sites are strongly encouraged to apply the patches referenced in the advisory.
Workarounds

In the absence of patching, the following workarounds have been proposed by the MIT Kerberos team:

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.

Systems Affected

VendorStatusDate Updated
3ComUnknown17-Mar-2003
Apple Computer Inc.Unknown17-Mar-2003
AT&TUnknown17-Mar-2003
AvayaUnknown17-Mar-2003
BSDIUnknown17-Mar-2003
Cisco Systems Inc.Unknown17-Mar-2003
ConectivaVulnerable9-May-2003
Cray Inc.Unknown21-Mar-2003
D-Link SystemsUnknown17-Mar-2003
Data GeneralUnknown17-Mar-2003
DebianVulnerable31-Mar-2003
F5 NetworksUnknown17-Mar-2003
Foundry Networks Inc.Unknown6-Mar-2003
FreeBSDUnknown17-Mar-2003
FujitsuUnknown21-Mar-2003
Gentoo LinuxVulnerable31-Mar-2003
Guardian Digital Inc. Unknown17-Mar-2003
Hewlett-Packard CompanyUnknown17-Mar-2003
HitachiNot Vulnerable4-Apr-2003
IBM-zSeriesUnknown17-Mar-2003
Ingrian NetworksNot Vulnerable10-Mar-2003
IntelUnknown17-Mar-2003
Juniper NetworksNot Vulnerable17-Mar-2003
KTH KerberosUnknown17-Mar-2003
Lotus SoftwareNot Vulnerable17-Mar-2003
Lucent TechnologiesUnknown17-Mar-2003
MandrakeSoftVulnerable1-Apr-2003
Microsoft CorporationNot Vulnerable20-Mar-2003
MiT Kerberos Development TeamVulnerable17-Mar-2003
MontaVista SoftwareUnknown17-Mar-2003
Multi-Tech Systems Inc.Unknown17-Mar-2003
NEC CorporationUnknown17-Mar-2003
NETBSDUnknown17-Mar-2003
NetBSDVulnerable4-Apr-2003
NetScreenUnknown17-Mar-2003
Network ApplianceUnknown17-Mar-2003
NeXTUnknown17-Mar-2003
NokiaUnknown17-Mar-2003
Nortel NetworksUnknown17-Mar-2003
OpenAFSVulnerable2-Apr-2003
OpenBSDVulnerable24-Mar-2003
Openwall GNU/*/LinuxUnknown21-Mar-2003
Red Hat Inc.Vulnerable2-Apr-2003
Redback Networks Inc.Unknown17-Mar-2003
Riverstone NetworksUnknown17-Mar-2003
SequentUnknown17-Mar-2003
SGIUnknown17-Mar-2003
Sony CorporationUnknown17-Mar-2003
Sun Microsystems Inc.Unknown17-Mar-2003
SuSE Inc.Unknown17-Mar-2003
The SCO Group (SCO Linux)Unknown17-Mar-2003
The SCO Group (SCO UnixWare)Unknown17-Mar-2003
UnisysUnknown17-Mar-2003
Wind River Systems Inc.Unknown17-Mar-2003
WirexVulnerable9-Apr-2003
XeroxNot Vulnerable9-May-2003

References


http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt

Credit

The CERT/CC thanks Sam Hartman, Ken Raeburn, and Tom Yu of the Kerberos group at MIT for their detailed analysis and report of this vulnerability.

This document was written by Chad Dougherty.

Other Information

Date Public03/15/2003
Date First Published03/20/2003 11:48:44 AM
Date Last Updated05/09/2003
CERT Advisory 
CVE NameCAN-2003-0138
US-CERT Technical Alerts 
Metric13.54
Document Revision15

If you have feedback, comments, or additional information about this vulnerability, please send us email.
 

 
Page Corner Image
Copyright 2003 Carnegie Mellon University
Disclaimers and copyright information
Get Adobe Reader Get Adobe Reader