MITKRB5-SA-2010-007 Multiple checksum handling vulnerabilities [CVE-2010-1324 CVE-2010-1323 CVE-2010-4020 CVE-2010-4021]
Tom Yu
tlyu at MIT.EDU
Tue Nov 30 14:13:42 EST 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MITKRB5-SA-2010-007
MIT krb5 Security Advisory 2010-007
Original release: 2010-11-30
Last update: 2010-11-30
Topic: Multiple checksum handling vulnerabilities
CVE-2010-1324
* krb5 GSS-API applications may accept unkeyed checksums
* krb5 application services may accept unkeyed PAC checksums
* krb5 KDC may accept low-entropy KrbFastArmoredReq checksums
CVSSv2 Vector: AV:N/AC:M/Au:N/C:N/I:C/A:N/E:POC/RL:OF/RC:C
CVSSv2 Base Score: 7.1
Access Vector: Network
Access Complexity: Medium
Authentication: None
Confidentiality Impact: None
Integrity Impact: Complete
Availability Impact: None
CVSSv2 Temporal Score: 5.6
Exploitability: Proof-of-Concept
Remediation Level: Official Fix
Report Confidence: Confirmed
CVE-2010-1323
* krb5 clients may accept unkeyed SAM-2 challenge checksums
* krb5 may accept KRB-SAFE checksums with low-entropy derived keys
CVSSv2 Vector: AV:N/AC:H/Au:N/C:N/I:C/A:N/E:POC/RL:OF/RC:C
CVSSv2 Base Score: 5.4
CVSSv2 Temporal Score: 4.2
CVE-2010-4020
* krb5 may accept authdata checksums with low-entropy derived keys
CVSSv2 Vector: AV:N/AC:M/Au:S/C:N/I:P/A:N/E:POC/RL:OF/RC:C
CVSSv2 Base Score: 3.5
CVSSv2 Temporal Score: 2.7
CVE-2010-4021
* krb5 KDC may issue unrequested tickets due to KrbFastReq forgery
CVSSv2 Vector: AV:N/AC:H/Au:S/C:N/I:P/A:N/E:POC/RL:OF/RC:C
CVSSv2 Base Score: 2.1
CVSSv2 Temporal Score: 1.6
See DETAILS for the expanded CVSSv2 metrics for CVE-2010-1323,
CVE-2010-4020, and CVE-2010-4021.
SUMMARY
=======
These vulnerabilities are in the MIT implementation of Kerberos
(krb5), but because these vulnerabilities arise from flaws in protocol
handling logic, other implementations may also be vulnerable.
CVE-2010-1324
MIT krb5 (releases krb-1.7 and newer) incorrectly accepts an unkeyed
checksum with DES session keys for version 2 (RFC 4121) of the GSS-API
krb5 mechanism.
MIT krb5 (releases krb5-1.7 and newer) incorrectly accepts an unkeyed
checksum for PAC signatures. Running exclusively krb5-1.8 or newer
KDCs blocks the attack.
MIT krb5 KDC (releases krb5-1.7 and newer) incorrectly accepts RFC
3961 key-derivation checksums using RC4 keys when verifying the
req-checksum in a KrbFastArmoredReq.
CVE-2010-1323
MIT krb5 clients (releases krb5-1.3 and newer) incorrectly accept an
unkeyed checksums in the SAM-2 preauthentication challenge.
MIT krb5 (releases krb5-1.3 and newer) incorrectly accepts RFC 3961
key-derivation checksums using RC4 keys when verifying KRB-SAFE
messages.
CVE-2010-4020
MIT krb5 (releases krb5-1.8 and newer) incorrectly accepts RFC 3961
key-derivation checksums using RC4 keys when verifying AD-SIGNEDPATH
and AD-KDC-ISSUED authorization data.
CVE-2010-4021
MIT krb5 KDC (release krb5-1.7 only) may issue tickets not requested
by a client, based on an attacker-chosen KrbFastArmoredReq.
IMPACT
======
CVE-2010-1324
An unauthenticated remote attacker can forge GSS tokens that are
intended to be integrity-protected but unencrypted, if the targeted
pre-existing application session uses a DES session key.
An authenticated remote attacker can forge PACs if using a KDC that
does not filter client-provided PAC data. This can result in
privilege escalation against a service that relies on PAC contents to
make authorization decisions.
An unauthenticated remote attacker has a 1/256 chance of swapping a
client-issued KrbFastReq into a different KDC-REQ, if the armor key is
RC4. The consequences are believed to be minor.
CVE-2010-1323
An unauthenticated remote attacker could alter a SAM-2 challenge,
affecting the prompt text seen by the user or the kind of response
sent to the KDC. Under some circumstances, this can negate the
incremental security benefit of using a single-use authentication
mechanism token.
An unauthenticated remote attacker has a 1/256 chance of forging
KRB-SAFE messages in an application protocol if the targeted
pre-existing session uses an RC4 session key. Few application
protocols use KRB-SAFE messages.
CVE-2010-4020
An authenticated remote attacker that controls a legitimate service
principal has a 1/256 chance of forging the AD-SIGNEDPATH signature if
the TGT key is RC4, allowing it to use self-generated "evidence"
tickets for S4U2Proxy, instead of tickets obtained from the user or
with S4U2Self. Configurations using RC4 for the TGT key are believed
to be rare.
An authenticated remote attacker has a 1/256 chance of forging
AD-KDC-ISSUED signatures on authdata elements in tickets having an RC4
service key, resulting in privilege escalation against a service that
relies on these signatures. There are no known uses of the KDC-ISSUED
authdata container at this time.
CVE-2010-4021
An authenticated remote attacker that controls a legitimate service
principal could obtain a valid service ticket to itself containing
valid KDC-generated authorization data for a client whose TGS-REQ it
has intercepted. The attacker could then use this ticket for
S4U2Proxy to impersonate the targeted client even if the client never
authenticated to the subverted service. The vulnerable configuration
is believed to be rare.
AFFECTED SOFTWARE
=================
CVE-2010-1324
Kerberos application client and server software (including third-party
applications) using GSS-API libraries from MIT releases krb5-1.7 and
newer are vulnerable to the DES GSS-API issue if they use GSS-API for
integrity protection of unencrypted messages.
Kerberos application server software (including third-party
applications) using libraries from MIT releases krb5-1.7 and newer are
vulnerable to the PAC issue.
Deployments running exclusively KDCs from releases krb5-1.8 and newer
are not vulnerable to the PAC issue because those KDCs discard
client-provided PAC authdata.
The MIT krb5 KDC in releases krb5-1.7 and newer is vulnerable to the
KrbFastReq swapping issue.
CVE-2010-1323
Initial credential acquisition clients (including kinit) in MIT
releases krb5-1.3 and newer are vulnerable to the SAM-2 issue.
Third-party applications that obtain initial Kerberos credentials
using libraries from these releases are also vulnerable.
Kerberos application client and server software (including third-party
applications) using libraries from MIT releases krb5 krb5-1.3 and
newer are vulnerable to the RC4 KRB-SAFE issue.
CVE-2010-4020
The AD-SIGNEDPATH issue affects the KDC in releases krb5-1.8 and
newer.
Kerberos application server software (including third-party
applications) using libraries from MIT releases krb5-1.8 and newer are
vulnerable to the AD-KDC-ISSUED problem. Deployments running
exclusively KDCs from releases krb5-1.8 and newer discard
client-provided AD-KDC-ISSUED authdata and are not vulnerable to this
issue.
CVE-2010-4021
The KDC from release krb5-1.7 only is vulnerable to the KrbFastReq
forgery issue.
FIXES
=====
* Upcoming releases in the krb5-1.8 and krb5-1.7 series will contain
fixes for these issues.
* The patches for this advisory do not cover CVE-2010-4021, which is a
minor issue already corrected in krb5-1.7.1.
A patch for the krb5-1.8 series is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch.txt
A PGP-signed patch is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch.txt.asc
A patch for the krb5-1.7 series is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch-r17.txt
A PGP-signed patch is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch-r17.txt.asc
A patch for the krb5-1.6 series is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch-r16.txt
A PGP-signed patch is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch-r16.txt.asc
A patch for the krb5-1.5 series is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch-r15.txt
A PGP-signed patch is available at
http://web.mit.edu/kerberos/advisories/2010-007-patch-r15.txt.asc
REFERENCES
==========
This announcement is posted at:
http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2010-007.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:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1324
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1323
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4020
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4021
ACKNOWLEDGMENTS
===============
Thanks to Sam Hartman for helping with analysis.
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/8B8DF501 2010-01-15 [expires: 2011-02-01]
uid MIT Kerberos Team Security Contact <krbcore-security at mit.edu>
DETAILS
=======
Background for RC4-keyed RFC 3961 checksum issues:
The hmac-sha1-des3, hmac-sha1-96-aes128, and hmac-sha1-96-aes256
checksum types are specified to be used with 3DES, AES128, and AES256
keys respectively, but MIT krb5 allows these checksum types to be used
with any type of key. All three checksum types make use of a key
derivation algorithm built around the block encryption operation of
the key's encryption type.
The arcfour-hmac and arcfour-hmac-exp encryption types are specified
in RFC 4757, and make use of a stream cipher instead of a block
cipher. The MIT krb5 implementation treats these encryption types as
having a cipher block size of one byte for the purposes of key
derivation. When the aforementioned checksum types perform key
derivation, they repeatedly invoke stream cipher encryption on
one-byte blocks. The result is a derived key whose contents alternate
between a known byte (which depends only on the key usage value) and a
byte whose values depend on the key. There are only 256 possible
derived keys for each key usage value.
CVE-2010-1324 (GSS-API issue):
RFC 4121 specifies version 2 of the krb5 GSS-API mechanism. It is
commonly used only with "newer" encryption types, but may be used with
any encryption type. RFC 4121 specifies that non-confidential Wrap
messages and Message Integrity Codes (MICs) are computed using the
required checksum type for the key's encryption type. MIT krb5 uses
the internal krb5int_c_mandatory_cksumtype function to look up this
checksum type. This function returns incorrect values for DES
encryption types, selecting unkeyed rather than keyed checksums.
If a GSS-API context is established using a DES key, the MIT krb5 code
will accept Wrap or MIC tokens in either the RFC 4121 or RFC 1964
style. An attacker can construct a Wrap or MIC token in the RFC 4121
style using unkeyed checksums.
CVE-2010-1324 (PAC issue):
Privilege Attribute Certificates (PACs) are a type of authorization
data specified in:
http://msdn.microsoft.com/en-us/library/cc237917(PROT.13).aspx
PACs contain two signature fields which bind the PAC to the server and
krbtgt keys; this signature is intended to prove that the PAC was
generated by the KDC and not by a client. PAC signatures are
specified to use the hmac-md5, hmac-sha1-96-aes128, or
hmac-sha1-96-aes256 keyed checksum types. The MIT krb5 code for
verifying PAC signatures does not verify that the checksum type
contained in the PAC is a keyed signature, so a client could use an
unkeyed checksum to "prove" that its made-up PAC data was generated by
a KDC. This attack would not work in the presence of a sufficiently
recent (1.8 or later) MIT KDC because the KDC would filter out
client-provided PAC authdata.
CVE-2010-1324 (KrbFastReq swapping issue):
The KDC may accept an RFC 3961 key-derivation checksum keyed with an
RC4 key in the req-checksum field of KrbArmoredFastReq. An attacker
has a 1/256 chance of guessing the derived key that would be required
to bind a captured encrypted KrbFastReq to a different KDC-REQ
message. This is probably at worst an auditing issue; the KDC will
log a successful authentication, but with the wrong parameters, and
the client will not necessarily be able to use the resulting ticket.
CVE-2010-1323 (SAM-2 issue):
CVSSv2 Base Score: 5.4
Access Vector: Network
Access Complexity: High
Authentication: None
Confidentiality Impact: None
Integrity Impact: Complete
Availability Impact: None
CVSSv2 Temporal Score: 4.2
Exploitability: Proof-of-Concept
Remediation Level: Official Fix
Report Confidence: Confirmed
SAM-2 is a preauthentication mechanism described in:
http://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-sam-03 (SAM2)
In this mechanism, a KDC sends a challenge to the client consisting of
a challenge body and a list of checksums. The client prompts the user
for Single-use Authentication Data (SAD), computes a reply key based
on the SAD and the parameters in the challenge body, and then tries to
verify each of the checksums against the body using the reply key. If
no checksum matches, the client assumes that the SAD value is
incorrect or the integrity of the challenge has been tampered with by
a party with no knowledge of the reply key. The MIT krb5 code for
verifying SAM-2 challenge signatures does not verify that the checksum
type is keyed, so an attacker alter a challenge and supply an unkeyed
signature, fooling the client into believing that the challenge body
was not tampered with. The general result would be that the client
would transmit an invalid reply to the KDC, causing preauthentication
to fail.
With non-challenge/response SAM tokens having low entropy (e.g., a
clock-based token with six decimal digits of readout), this may allow
an attacker to learn the SAD value by a precomputation attack,
negating the incremental security benefit of using a SAM token. This
would allow the attacker to authenticate to the KDC as the user, or to
impersonate the KDC to the user, provided that the user's password has
been previously captured.
CVE-2010-1323 (KRB-SAFE RC4 issue):
The KRB-SAFE message is intended for the integrity protection of
cleartext application data. An attacker can forge KRB-SAFE messages
in an existing application protocol session with 1/256 probability of
success, if the session uses an RC4 session key.
CVE-2010-4020 (authdata RC4 issue):
CVSSv2 Base Score: 3.5
Access Vector: Network
Access Complexity: Medium
Authentication: Single
Confidentiality Impact: None
Integrity Impact: Partial
Availability Impact: None
CVSSv2 Temporal Score: 2.7
Exploitability: Proof-of-Concept
Remediation Level: Official Fix
Report Confidence: Confirmed
S4U2proxy is a Microsoft protocol extension that allows a service to
impersonate a user to another service, in a constrained way:
http://msdn.microsoft.com/en-us/library/cc246071(PROT.13).aspx
MIT and Heimdal implementations of Kerberos use an extension to take
the place of the Windows PAC in S4U2proxy evidence tickets:
http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation
The signature in the SIGNEDPATH authorization data uses the TGT key,
which is only known to the KDC. If the TGT key is RC4, then a service
can forge this signature with a 1/256 chance of success by supplying
an inappropriate checksum type.
CVE-2010-4021 (KrbFastReq forgery issue):
CVSSv2 Base Score: 2.1
Access Vector: Network
Access Complexity: High
Authentication: Single
Confidentiality Impact: None
Integrity Impact: Partial
Availability Impact: None
CVSSv2 Temporal Score: 1.6
Exploitability: Proof-of-Concept
Remediation Level: Official Fix
Report Confidence: Confirmed
In release krb5-1.7, but not newer releases, the KDC allows an
arbitrary TGT credential to serve as the armor for TGS requests,
allowing the inner request to be arbitrarily altered by an attacker
who controls a service principal. (The attacker has full knowledge of
the armor key, having provided the armor ticket.) The resulting
ticket is useless to both client and attacker unless the named service
principal in the forged request is that of the attacker.
By intercepting a legitimate TGS-REQ message, a malicious service that
has S4U2Proxy privileges can rewrite the inner request so that the
service named in the request is itself, and then capture the issued
ticket for use as an evidence ticket in a S4U2Proxy request to
impersonate the client to another service, even though the client
never asked for a ticket for the malicious service. Since krb5-1.7
does not natively support S4U2proxy, the attack is only feasible in
certain cross-realm configurations, which are believed to be rare,
involving Active Directory domains that grant S4U2proxy privileges to
services in a non-AD Kerberos foreign realm.
REVISION HISTORY
================
2010-11-30 original release
Copyright (C) 2010 Massachusetts Institute of Technology
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkz1SjoACgkQSO8fWy4vZo5CGgCePDfxaWdGcX70V4U83JUbi9uF
VXoAoO0eP1MPEOUZt096Xsgyv1fR1k1u
=BFph
-----END PGP SIGNATURE-----
_______________________________________________
kerberos-announce mailing list
kerberos-announce at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce
More information about the Kerberos
mailing list