security/CVE-2020-25722.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4
   5 <head>
   6 <title>Samba - Security Announcement Archive</title>
   7 </head>
   8
   9 <body>
  10
  11    <H2>CVE-2020-25722.html:</H2>
  12
  13 <p>
  14 <pre>
  15 ===========================================================
  16 == Subject:     Samba AD DC did not do suffienct access and
  17 ==              conformance checking of data stored.
  18 ==
  19 == CVE ID#:     CVE-2020-25722
  20 ==
  21 == Versions:    Samba 4.0.0 and later
  22 ==
  23 == Summary:     At a number of points in the Samba AD DC
  24 ==              per-attribute and schema based permission checks
  25 ==              were not correctly implemented, allowing up
  26 ==              to total domain compromise.
  27 ===========================================================
  28
  29 ===========
  30 Description
  31 ===========
  32
  33 Samba as an Active Directory Domain Controller has to take care to
  34 protect a number of sensitive attributes, and to follow a security
  35 model from Active Directory that relies totally on the intersection of
  36 NT security descriptors and the underlying X.500 Directory Access
  37 Protocol (as then expressed in LDAP) schema constraints for security.
  38
  39 Some attributes in Samba AD are sensitive, they apply to one object
  40 but protect others.
  41
  42 Users who can set msDS-AllowedToDelegateTo can become any user in the
  43 domain on the server pointed at by this list.  Likewise in a domain
  44 mixed with Microsoft Windows, Samba's lack of protection of sidHistory
  45 would be a similar issue.
  46
  47 This would be limited to users with the right to create users or
  48 modify them (typically those who created them), however, due to
  49 other flaws, all users are able to create new user objects.
  50
  51 Finally, Samba did not enforce userPrincipalName and
  52 servicePrincipalName uniqueness, nor did it correctly implement the
  53 "validated SPN" feature allowing machine accounts to safely set their
  54 own SPN (the checks were easily bypassed and additionally should
  55 have been restricted to objectClass=computer).
  56
  57 Samba has implemented this feature, which avoids a denial of service
  58 (UPNs) or service impersonation (SPNs) between users privileged to add
  59 users to the domian (but see the above point).
  60
  61 This release adds a feature similar in goal but broader in
  62 implementation than that found in the Windows 2012 Forest Functional
  63 level.
  64
  65 =================
  66 Behaviour changes
  67 =================
  68
  69 After this release, in addressing the above issues, significant new
  70 restrictions apply to the userPrincipalName, servicePrincipalName and
  71 sAMAccountName attributes on users and computers, particularly for
  72 non-administrators.
  73
  74 As a non-administrator (eg a user delegated the right to create
  75 users/computers):
  76  * objects of objectclass computer must have a userAccountControl flag
  77  including UF_WORKSTATION_TRUST_ACCOUNT or UF_SERVER_TRUST_ACCOUNT
  78  * objects of objectclass computer must have a sAMAccountName ending
  79  in $
  80
  81 For all new computer objects, if not specified otherwise the default
  82 userAcocuntControl is UF_WORKSTATION_TRUST_ACCOUNT.
  83
  84 For all user/computer objects, userPrincipalName must be unique,
  85 including the implicit UPN of &lt;sAMAccountName&gt;@&lt;REALM&gt;.  This applies
  86 both to modifications of userPrincipalName and sAMAccountName.
  87
  88 For all user/computer objects, servicePrincipalName must be unique,
  89 including the implict SPN aliases from the sPNMappings feature.
  90
  91 The only exception is that a user who wants to create a new SPN of
  92 (eg) http/myhost.samba.example.org may do so if they have write
  93 permission on host/myhost.samba.example.org.
  94
  95 Note that, due to Samba's internal logic for this check, a no-op
  96 modify on the entry holding host/myhost.samba.example.org may show up
  97 in the audit logs if enabled.
  98
  99 Finally, it should be noted that Samba's choice of UPN and SPN
 100 restrictions does not match that in Microsoft Windows and introduced
 101 in FL 2012 (Samba is stricter) and so behaviour in and the security
 102 properties of a mixed Samba-Windows domain would depend on the DC
 103 acting on any such query or modification.
 104
 105 Also, opt-out flags in dSHeuristics used by Microsoft Windows for
 106 these features are not implemented in Samba.
 107
 108 ==================
 109 Patch Availability
 110 ==================
 111
 112 Patches addressing both these issues have been posted to:
 113
 114     https://www.samba.org/samba/security/
 115
 116 Additionally, Samba  4.15.2, 4.14.10 and 4.13.14 have been issued
 117 as security releases to correct the defect.  Samba administrators are
 118 advised to upgrade to these releases or apply the patch as soon
 119 as possible.
 120
 121 ==================
 122 CVSSv3 calculation
 123 ==================
 124
 125 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8)
 126
 127 ==========
 128 Workaround
 129 ==========
 130
 131
 132 =======
 133 Credits
 134 =======
 135
 136 Originally reported by Andrew Bartlett.
 137
 138 Patches provided by:
 139  - Andrew Bartlett of Catalyst and the Samba Team.
 140  - Douglas Bagnall of Catalyst and the Samba Team.
 141  - Nadezhda Ivanova of Symas and the Samba Team
 142  - Joseph Sutton of Catalyst and the Samba Team
 143
 144 Catalyst wishes to thank Univention Gmbh and Symas Corporation in
 145 particular for their support towards the production of this fix.
 146
 147 Advisory written by Andrew Bartlett of Catalyst
 148
 149 ==========================================================
 150 == Our Code, Our Bugs, Our Responsibility.
 151 == The Samba Team
 152 ==========================================================
 153 </pre>
 154 </body>
 155 </html>