Attachment 16977 Details for Bug 14564 – advisory text (v03)

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:

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
>==========================================================
>

Flags:

metze: review+

Actions: View

Attachments on bug 14564: 16914 | 16916 | 16977