The Samba-Bugzilla – Attachment 16977 Details for
Bug 14564
CVE-2020-25722 [SECURITY] AD DC UPN vs samAccountName not checked (top-level bug for AD DC validation issues)
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
advisory text (v03)
CVE-2020-25722-advisory-v3.txt (text/plain), 4.91 KB, created by
Andrew Bartlett
on 2021-11-09 08:00:57 UTC
(
hide
)
Description:
advisory text (v03)
Filename:
MIME Type:
Creator:
Andrew Bartlett
Created:
2021-11-09 08:00:57 UTC
Size:
4.91 KB
patch
obsolete
>=========================================================== >== Subject: Samba AD DC did not do suffienct access and >== conformance checking of data stored. >== >== CVE ID#: CVE-2020-25722 >== >== Versions: Samba 4.0.0 and later >== >== Summary: At a number of points in the Samba AD DC >== per-attribute and schema based permission checks >== were not correctly implemented, allowing up >== to total domain compromise. >=========================================================== > >=========== >Description >=========== > >Samba as an Active Directory Domain Controller has to take care to >protect a number of sensitive attributes, and to follow a security >model from Active Directory that relies totally on the intersection of >NT security descriptors and the underlying X.500 Directory Access >Protocol (as then expressed in LDAP) schema constraints for security. > >Some attributes in Samba AD are sensitive, they apply to one object >but protect others. > >Users who can set msDS-AllowedToDelegateTo can become any user in the >domain on the server pointed at by this list. Likewise in a domain >mixed with Microsoft Windows, Samba's lack of protection of sidHistory >would be a similar issue. > >This would be limited to users with the right to create users or >modify them (typically those who created them), however, due to >other flaws, all users are able to create new user objects. > >Finally, Samba did not enforce userPrincipalName and >servicePrincipalName uniqueness, nor did it correctly implement the >"validated SPN" feature allowing machine accounts to safely set their >own SPN (the checks were easily bypassed and additionally should >have been restricted to objectClass=computer). > >Samba has implemented this feature, which avoids a denial of service >(UPNs) or service impersonation (SPNs) between users privileged to add >users to the domian (but see the above point). > >This release adds a feature similar in goal but broader in >implementation than that found in the Windows 2012 Forest Functional >level. > >================= >Behaviour changes >================= > >After this release, in addressing the above issues, significant new >restrictions apply to the userPrincipalName, servicePrincipalName and >sAMAccountName attributes on users and computers, particularly for >non-administrators. > >As a non-administrator (eg a user delegated the right to create >users/computers): > * objects of objectclass computer must have a userAccountControl flag > including UF_WORKSTATION_TRUST_ACCOUNT or UF_SERVER_TRUST_ACCOUNT > * objects of objectclass computer must have a sAMAccountName ending > in $ > >For all new computer objects, if not specified otherwise the default >userAcocuntControl is UF_WORKSTATION_TRUST_ACCOUNT. > >For all user/computer objects, userPrincipalName must be unique, >including the implicit UPN of <sAMAccountName>@<REALM>. This applies >both to modifications of userPrincipalName and sAMAccountName. > >For all user/computer objects, servicePrincipalName must be unique, >including the implict SPN aliases from the sPNMappings feature. > >The only exception is that a user who wants to create a new SPN of >(eg) http/myhost.samba.example.org may do so if they have write >permission on host/myhost.samba.example.org. > >Note that, due to Samba's internal logic for this check, a no-op >modify on the entry holding host/myhost.samba.example.org may show up >in the audit logs if enabled. > >Finally, it should be noted that Samba's choice of UPN and SPN >restrictions does not match that in Microsoft Windows and introduced >in FL 2012 (Samba is stricter) and so behaviour in and the security >properties of a mixed Samba-Windows domain would depend on the DC >acting on any such query or modification. > >Also, opt-out flags in dSHeuristics used by Microsoft Windows for >these features are not implemented in Samba. > >================== >Patch Availability >================== > >Patches addressing both these issues have been posted to: > > https://www.samba.org/samba/security/ > >Additionally, Samba 4.15.2, 4.14.10 and 4.13.14 have been issued >as security releases to correct the defect. Samba administrators are >advised to upgrade to these releases or apply the patch as soon >as possible. > >================== >CVSSv3 calculation >================== > >CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8) > >========== >Workaround >========== > > >======= >Credits >======= > >Originally reported by Andrew Bartlett. > >Patches provided by: > - Andrew Bartlett of Catalyst and the Samba Team. > - Douglas Bagnall of Catalyst and the Samba Team. > - Nadezhda Ivanova of Symas and the Samba Team > - Joseph Sutton of Catalyst and the Samba Team > >Catalyst wishes to thank Univention Gmbh and Symas Corporation in >particular for their support towards the production of this fix. > >Advisory written by Andrew Bartlett of Catalyst > >========================================================== >== Our Code, Our Bugs, Our Responsibility. >== The Samba Team >========================================================== >
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
Flags:
metze
:
review+
Actions:
View
Attachments on
bug 14564
:
16914
|
16916
| 16977