Package: heimdal / 7.1.0+dfsg-13+deb9u3

0021-CVE-2018-16860-Heimdal-KDC-Reject-PA-S4U2Self-with-u.patch Patch series | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
From: Isaac Boukris <iboukris@gmail.com>
Date: Tue, 14 May 2019 09:03:18 -0400
Subject: CVE-2018-16860 Heimdal KDC: Reject PA-S4U2Self with unkeyed checksum

S4U2Self is an extension to Kerberos used in Active Directory to allow
a service to request a kerberos ticket to itself from the Kerberos Key
Distribution Center (KDC) for a non-Kerberos authenticated user
(principal in Kerboros parlance). This is useful to allow internal
code paths to be standardized around Kerberos.

S4U2Proxy (constrained-delegation) is an extension of this mechanism
allowing this impersonation to a second service over the network. It
allows a privileged server that obtained a S4U2Self ticket to itself
to then assert the identity of that principal to a second service and
present itself as that principal to get services from the second
service.

There is a flaw in Samba's AD DC in the Heimdal KDC. When the Heimdal
KDC checks the checksum that is placed on the S4U2Self packet by the
server to protect the requested principal against modification, it
does not confirm that the checksum algorithm that protects the user
name (principal) in the request is keyed.  This allows a
man-in-the-middle attacker who can intercept the request to the KDC to
modify the packet by replacing the user name (principal) in the
request with any desired user name (principal) that exists in the KDC
and replace the checksum protecting that name with a CRC32 checksum
(which requires no prior knowledge to compute).

This would allow a S4U2Self ticket requested on behalf of user name
(principal) user@EXAMPLE.COM to any service to be changed to a
S4U2Self ticket with a user name (principal) of
Administrator@EXAMPLE.COM. This ticket would then contain the PAC of
the modified user name (principal).

==================
CVSSv3 calculation
==================

CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (7.5)

=========================
Workaround and Mitigation
=========================

If server does not take privileged actions based on Kerberos tickets
obtained by S4U2Self nor obtains Kerberos tickets via further
S4U2Proxy requests then this issue cannot be exploited.

Note that the path to an exploit is not generic, the KDC is not harmed
by the malicious checksum, it is the client service requesting the
ticket being mislead, because it trusted the KDC to return the correct
ticket and PAC.

It is out of scope for Samba to describe all of the possible tool
chains that might be vulnerable. Here are two examples of possible
exploits in order to explain the issue more clearly.

1). SFU2Self might be used by a web service authenticating an end user
via OAuth, Shibboleth, or other protocols to obtain a S4U2Self
Kerberos service ticket for use by any Kerberos service principal the
web service has a keytab for.  One example is acquiring an AFS token
by requesting an afs/cell@REALM service ticket for a client via
SFU2Self.  With this exploit an organization that deploys a KDC built
from Heimdal (be it Heimdal directly or vendor versions such as found
in Samba) is vulnerable to privilege escalation attacks.

2). If a server authenticates users using X509 certificates, and then
uses S4U2Self to obtain a Kerberos service ticket on behalf of the
user (principal) in order to authorize access to local resources, a
man-in-the-middle attacker could allow a non-privileged user to access
privileged resources being protected by the server, or privileged
resources being protected by a second server, if the first server uses
the S4U2Proxy extension in order to get a new Kerberos service ticket
to obtain access to the second server.

In both these scenarios under conditions allowing man-in-the-middle
active network protocol manipulation, a malicious user could
authenticate using the non-Kerborized credentials of an unprivileged
user, and then elevate its privileges by intercepting the packet from
the server to the KDC and changing the requested user name (principal).

The only Samba clients that use S4U2Self are:

- the "net ads kerberos pac dump" (debugging) tool.

- the CIFS proxy in the deprecated/developer-only NTVFS file
server. Note this code is not compiled or enabled by default.

In particular, winbindd does *not* use S4U2Self.

Finally, MIT Kerberos and so therefore the experimental MIT KDC backend
for Samba AD is understood not to be impacted.

===============
Further Reading
===============

There is more detail on and a description of the protocols in

[MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained
Delegation Protocol
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/

=======
Credits
=======

Originally reported by Isaac Boukris and Andrew Bartlett of the Samba
Team and Catalyst.

Patches provided by Isaac Boukris.

Advisory written by Andrew Bartlett of the Samba Team and Catalyst,
with contributions from Isaac Boukris, Jeffrey Altman and Jeremy
Allison.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=13685
Change-Id: I4ac69ebf0503eb999a7d497a2c30fe4d293a8cc8
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Signed-off-by: Jeffrey Altman <jaltman@auristor.com>
---
 kdc/krb5tgs.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kdc/krb5tgs.c b/kdc/krb5tgs.c
index 9850381..dd4e185 100644
--- a/kdc/krb5tgs.c
+++ b/kdc/krb5tgs.c
@@ -1986,6 +1986,13 @@ server_lookup:
 		goto out;
 	    }
 
+	    if (!krb5_checksum_is_keyed(context, self.cksum.cksumtype)) {
+		free_PA_S4U2Self(&self);
+		kdc_log(context, config, 0, "Reject PA-S4U2Self with unkeyed checksum");
+		ret = KRB5KRB_AP_ERR_INAPP_CKSUM;
+		goto out;
+	    }
+
 	    ret = _krb5_s4u2self_to_checksumdata(context, &self, &datack);
 	    if (ret)
 		goto out;