Attachment 16343 Details for Bug 14557 – Possible letter to Microsoft for comment.

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:

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

Actions: View

Attachments on bug 14557: 16339 | 16340 | 16341 | 16342 | 16343 | 16351 | 16925 | 16940