MITKRB5-SA-2009-004 [CVE-2009-4212] integer underflow in AES and RC4 decryption

Tue Jan 12 14:05:34 EST 2010

Integer underflow bugs in the AES and RC4 decryption operations of the
crypto library of the MIT Kerberos software can cause crashes, heap
corruption, or, under extraordinarily unlikely conditions, arbitrary
code execution.  Only releases krb5-1.3 and later are vulnerable, as
earlier releases did not contain the functionality implemented by the
vulnerable code.

This is an implementation vulnerability in MIT krb5, and is not a
vulnerability in the Kerberos protocol.

IMPACT
======

An unauthenticated remote attacker can, by inducing the decryption of
an invalid AES or RC4 ciphertext, cause a crash or heap corruption,
or, under extraordinarily unlikely conditions, arbitrary code
execution.  A successful code-execution attack against a KDC can
compromise all services relying on that KDC for authentication.
However, the most probable outcome is a crash due to a memory fault or
abort() call.  An attacker with a valid account in the relevant
Kerberos realm has a marginally higher chance of success to execute
arbitrary code, but the probability is still very low.  Therefore, the
given Confidentiality Impact and Integrity Impact metrics of
"Complete" represent theoretical worst-case scenarios and are both
more realistically characterized as "Partial".

AFFECTED SOFTWARE
=================

* KDC and application servers in MIT krb5-1.3 and later releases are
  vulnerable.  Earlier releases did not contain the functionality
  implemented by the vulnerable code.

* Third-party applications linked with the libraries from vulnerable
  releases are also vulnerable.

FIXES
=====

* The upcoming krb5-1.7.1 and krb5-1.6.4 releases will contain a fix
  for this vulnerability.

* For the krb5-1.7 release, apply the patch available at:

  http://web.mit.edu/kerberos/advisories/2009-004-patch_1.7.txt

  A PGP-signed patch is available at

  http://web.mit.edu/kerberos/advisories/2009-004-patch_1.7.txt.asc

* For the krb5-1.6 releases, apply the patch available at:

  http://web.mit.edu/kerberos/advisories/2009-004-patch_1.6.3.txt

  A PGP-signed patch is available at

  http://web.mit.edu/kerberos/advisories/2009-004-patch_1.6.3.txt.asc

* The krb5-1.6.3 patch might apply successfully to older releases.

REFERENCES
==========

This announcement is posted at:

  http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2009-004.txt

This announcement and related security advisories may be found on the
MIT Kerberos security advisory page at:

        http://web.mit.edu/kerberos/advisories/index.html

The main MIT Kerberos web page is at:

        http://web.mit.edu/kerberos/index.html

CVSSv2:

    http://www.first.org/cvss/cvss-guide.html
    http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2

CVE: CVE-2009-4212
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4212

CONTACT
=======

The MIT Kerberos Team security contact address is
<krbcore-security at mit.edu>.  When sending sensitive information,
please PGP-encrypt it using the following key:

pub   2048R/D9058C24 2009-01-26 [expires: 2010-02-01]
uid     MIT Kerberos Team Security Contact <krbcore-security at mit.edu>

DETAILS
=======

The greatest risk is from AES decryption of invalid ciphertexts, which
can theoretically lead to arbitrary code execution under
extraordinarily unlikely conditions.  Other scenarios are more likely
to lead to denial of service.

This advisory makes some reasonable assumptions about the platform.
We assume that attempts to invoke malloc() to allocate nearly SIZE_MAX
bytes will fail, which is reasonable for conventional memory
architectures.  We also assume that the process has less than UINT_MAX
contiguous bytes of heap address space mapped, which is reasonable
given likely hardware and operating system configurations.

The Kerberos protocol specifications define the format of valid
ciphertexts encrypted with AES (in RFC 3962) or RC4 (in RFC 4757)
ciphers.  Valid ciphertexts have a minimum length, as they include
HMAC values and random confounders.  The implementation of the AES and
RC4 decryption operations does not adequately check that the provided
ciphertext meets the minimum length requirements of the ciphertext
format, and proceeds as if the minimums were already satisfied.  The
decryption operations perform integer subtractions that underflow when
the minimums are not satisfied.

The integer underflows can cause the AES decryption operation to write
to memory located before the caller's output buffer.  This behavior
represents the highest risk for execution of arbitrary code, but this
risk is still fairly small.  On platforms where malloc(0) (a request
to allocate zero bytes) returns a null pointer, this behavior will not
occur, because this null pointer result triggers adequate error
handling.

The data written during this event is the result of the AES-CTS
decryption of the 32 bytes preceding the input buffer.  The attacker
might not be able to directly influence the contents of the 32 bytes
preceding the input buffer, and might not know the encryption key that
will be used.  Without knowledge of the encryption key, the attacker
has effectively no chance to predict which byte values will be
written.  Due to the strong cryptographic properties of AES, for an
attacker who knows the encryption key but who does not have perfect
knowledge of the bytes to be decrypted, the probability of producing
the desired bytes is one in the number of possible uncontrolled values
of the bytes to be decrypted.

Other possible consequences of the integer underflow in the AES
decryption code include a crash due to an explicit abort() call inside
a section of code that checks (imperfectly) for invalid lengths.

The related integer underflow in the RC4 decryption code can cause an
attempt to copy nearly UINT_MAX bytes from the decryption buffer to
the output buffer, most likely causing a crash from a memory fault.
In the unlikely event that the copy does not fault (only really
possible on 64-bit platforms), there is a risk of heap corruption and
arbitrary code execution.

On 64-bit platforms, where an attempt to malloc() nearly UINT_MAX
bytes is more likely to succeed, the decryption code may attempt to
decrypt nearly UINT_MAX bytes, leading to either an ordinary
(correctly handled) error condition due to (almost certain) HMAC
validation failure or to a crash due to a memory fault (if decrypting
beyond the end of the input buffer crosses over into invalid address
space).

REVISION HISTORY
================

2010-01-12      original release

Copyright (C) 2009 Massachusetts Institute of Technology
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)

iEYEARECAAYFAktMqfAACgkQSO8fWy4vZo4cggCgoMQOq/CF68tdzP1n+BwneJG+
vrIAmwX9X8LeO6gOXW9X+2jetti2pYGG
=d7/O
-----END PGP SIGNATURE-----