CVE-2018-20217 (published 2018-12-26T21:29Z)

A Reachable Assertion issue was discovered in the KDC in MIT Kerberos 5 (aka krb5) before 1.17. If an attacker can obtain a krbtgt ticket using an older encryption type (single-DES, triple-DES, or RC4), the attacker can crash the KDC by making an S4U2Self request.

Severity: LOW
CVSS v2 base score: 3.5 (AV:N/AC:M/Au:S/C:N/I:N/A:P)
CVSS v3 base score: 5.3, MEDIUM (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)

Weakness information:
cwe_id: CWE-617
cwe_name: Reachable Assertion
description: The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
extended_description: 
            While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service.
            For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service.
         
         

Fix information:
repo_url: https://github.com/krb5/krb5
commit_details: repo_url: https://github.com/krb5/krb5
author: Isaac Boukris
author_date: 2018-12-03 02:33:07+02:00
msg: Ignore password attributes for S4U2Self requests

For consistency with Windows KDCs, allow protocol transition to work
even if the password has expired or needs changing.

Also, when looking up an enterprise principal with an AS request,
treat ERR_KEY_EXP as confirmation that the client is present in the
realm.

[ghudson@mit.edu: added comment in kdc_process_s4u2self_req(); edited
commit message]

ticket: 8763 (new)
tags: pullup
target_version: 1.17
repository: repo_url: https://github.com/krb5/krb5
repo_name: krb5/krb5
description: mirror of MIT krb5 repository
repo_language: C
owner: krb5
file_changes: filename: kdc_util.c
change_type: ModificationType.MODIFY
diff: @@ -1607,6 +1607,11 @@ kdc_process_s4u2self_req(kdc_realm_t *kdc_active_realm,
 
         memset(&no_server, 0, sizeof(no_server));
 
+        /* Ignore password expiration and needchange attributes (as Windows
+         * does), since S4U2Self is not password authentication. */
+        princ->pw_expiration = 0;
+        clear(princ->attributes, KRB5_KDB_REQUIRES_PWCHANGE);
+
         code = validate_as_request(kdc_active_realm, request, *princ,
                                    no_server, kdc_time, status, &e_data);
         if (code) {

programming_language: C
filename: s4u_creds.c
change_type: ModificationType.MODIFY
diff: @@ -116,7 +116,7 @@ s4u_identify_user(krb5_context context,
     code = k5_get_init_creds(context, &creds, &client, NULL, NULL, 0, NULL,
                              opts, krb5_get_as_key_noop, &userid, &use_master,
                              NULL);
-    if (code == 0 || code == KRB5_PREAUTH_FAILED) {
+    if (!code || code == KRB5_PREAUTH_FAILED || code == KRB5KDC_ERR_KEY_EXP) {
         *canon_user = userid.user;
         userid.user = NULL;
         code = 0;

programming_language: C
filename: t_s4u.py
change_type: ModificationType.MODIFY
diff: @@ -19,6 +19,14 @@ pservice2 = 'p:' + service2
 # Get forwardable creds for service1 in the default cache.
 realm.kinit(service1, None, ['-f', '-k'])
 
+# Try S4U2Self for user with a restricted password.
+realm.run([kadminl, 'modprinc', '+needchange', realm.user_princ])
+realm.run(['./t_s4u', 'e:user', '-'])
+realm.run([kadminl, 'modprinc', '-needchange',
+          '-pwexpire', '1/1/2000', realm.user_princ])
+realm.run(['./t_s4u', 'e:user', '-'])
+realm.run([kadminl, 'modprinc', '-pwexpire', 'never', realm.user_princ])
+
 # Try krb5 -> S4U2Proxy with forwardable user creds.  This should fail
 # at the S4U2Proxy step since the DB2 back end currently has no
 # support for allowing it.

programming_language: Python