The Samba-Bugzilla – Attachment 16343 Details for
Bug 14557
CVE-2020-25721 [SECURITY] KDC canonicalisation and mapping rules: challenges and hardening
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
Possible letter to Microsoft for comment.
file_14557.txt (text/plain), 2.83 KB, created by
Andrew Bartlett
on 2020-11-17 02:05:27 UTC
(
hide
)
Description:
Possible letter to Microsoft for comment.
Filename:
MIME Type:
Creator:
Andrew Bartlett
Created:
2020-11-17 02:05:27 UTC
Size:
2.83 KB
patch
obsolete
>G'Day Microsoft, > >In traditional Kerberos, authorization is not well addressed, and is typically done by a name-based lookup based on the principal name in the returned ticket. > >Active directory extended this notion to add the PAC, which contains the final, certain identity of the user encoded in the PAC_LOGON_INFO. > >However, many unix-history Kerberos acceptors still do not know how to read the PAC, so operate based on the name alone. > >The reason this mail is maked [SECURITY] is that for Samba, we too make this mistake - in attempting to be open to non-AD Kerberos realms we allow Samba to be tricked into this mode of operation also. > >This would not normally be a major issue, except that Active Directory also supports name aliases. The aliases from COMPUTERNAME (in the ticket) -> COMPUTERNAME$ (in the directory) (MS-KILE 3.3.5.6.1Client Principal Lookup) is the most dangerous, as many AD installations allow the creation of new computer accounts with arbitrary names. > >As well as principal aliases, Active Directory introduced 'name canonicalisation'. This was added as a Kerberos protocol feature, and the net result of it is that for Windows clients (which request it by default) the target server will always get sAMAccountName@REALM. > >Many applications are therefore coded with this expectation. > >However, it is well established that Kerberos aliases can break name-based authorisation, if name canonicalisation is not requested: >https://k5wiki.kerberos.org/wiki/Projects/Aliases#Client_principals_2 > >Samba has extensive tests for the name canonicalisation and sadly we know that in the presence of implicit or explicit aliases, if the AS-REQ does not request canonicalisation then the eventual ticket will match the attacker-controlled name exactly. > >Where Samba fails to find the user in Active Directory, we will fallback to the local user. The most obvious mapping to be concerned about is root -> root$ (allowing a ticket with root@REALM). > >I'm quite concerned that Samba may not be the only application that did not expect this: 'nsswitch' ID mapping via getpwnam() seems quite common in NFSv4 for example. In other spaces, mod_auth_kerb for Apache is well-known to be named-based, as is OpenSSH (via the krb5 auth_to_local mapping). > >My request is this, given this issue only impacts on non-Microsoft products that do not strictly require a Kerberos PAC: Is Microsoft interested in protecting the industry at the source (KDC of the AD DC) and adopting a design like this from FreeIPA: >https://www.freeipa.org/page/V4/Kerberos_principal_aliases#Design >or take some other approach so that the KDC prints tickets to target servers that only sent the canonicalised name: sAMAccountName@REALM? > >If so, does this raise to a level where we should have a coordinated process, or should Samba experiment with a fix first? > >Andrew Bartlett
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 14557
:
16339
|
16340
|
16341
|
16342
|
16343
|
16351
|
16925
|
16940