-----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 (dot) edu [email concealed]>. 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 (dot) edu [email concealed]> 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-----