=========================================================== == Subject: Access controlled AD LDAP attributes can be discovered == == CVE ID#: CVE-2023-0614 == == Versions: All Samba releases since Samba 4.0 == == Summary: The fix in 4.6.16, 4.7.9, 4.8.4 and 4.9.7 for CVE-2018-10919 Confidential attribute disclosure via LDAP filters was insufficient and an attacker may be able to obtain confidential BitLocker recovery keys from a Samba AD DC. Installations with such secrets in their Samba AD should assume they have been obtained and need replacing. =========================================================== =========== Description =========== In Active Directory, there are essentially four different classes of attributes. - Secret attributes (such as a user, computer or domain trust password) that are never disclosed and are not available to search against over LDAP. This is a hard-coded list, and since Samba 4.8 these are additionally encrypted in the DB with a per-DB key. - Confidential attributes (marked as such in the schema) that have a default access restriction allowing access only to the owner of the object. While a Samba AD Domain makes these attributes available, thankfully by default it will not have any of these confidential attributes set, as they are only added by clients after configuration (typically via a GPO). Examples of confidential data stored in Active Directory include BitLocker recovery keys, TPM owner passwords, and certificate secret keys stored with Credential Roaming. - Access controlled attributes (for reads or writes), Samba will honour the access control specified in the ntSecurityDescriptor. - Public attributes for read. Most attributes in Active Directory are available to read by all authenticated users. Because the access control rules for a given attribute are not consistent between objects, Samba implemented access control restrictions only after matching objects against the filter. Taking each of the above classes in turn: - Secret attributes are prevented from disclosure firstly by redaction of the LDAP filter, and secondly by the fact that they are still encrypted during filter processing (by default). - Confidential and access controlled attributes were subject to an attack using LDAP filters. With this security patch, for attributes mentioned in the search filter, Samba will perform a per-object access control evaluation before LDAP filter matching on the attribute, preventing unauthorised disclosure of the value of (for example) BitLocker recovery keys. It is not expected that all similar attacks have been prevented, and it is likely still possible to determine if an object or attribute on an object is present, but not to obtain the contents. ============= Further steps ============= Evidence of an attack will not show up in the logs, except at the highly verbose level 10, and there is no record as to if a previous attribute disclosure has taken place. In addition to updating Samba, it is strongly recommended that steps be taken to ensure that data that may have been leaked from confidential or otherwise access-controlled attributes is no longer useful. Such steps may include, but are not limited to, re-encrypting BitLocker encrypted drives, changing TPM passwords, and revoking and re-issuing certificates that are stored by Credential Roaming (with new secret keys). =================== Impacted attributes =================== In addition to any per-object access control restrictions, the following attributes in the 2012R2 AD schema have SEARCH_FLAG_CONFIDENTIAL set in the searchFlags by default: msDS-IssuerCertificates msDS-TransformationRulesCompiled Bitlocker: msFVE-KeyPackage msFVE-RecoveryPassword Group Managed Service Accounts: msKds-CreateTime msKds-DomainID msKds-KDFAlgorithmID msKds-KDFParam msKds-PrivateKeyLength msKds-PublicKeyLength msKds-RootKeyData msKds-SecretAgreementAlgorithmID msKds-SecretAgreementParam msKds-UseStartTime msKds-Version (this AD DC feature is not implemented in Samba, and exists only in Windows 2012 and later, but could have been replicated to Samba in a mixed domain): msPKIAccountCredentials msPKI-CredentialRoamingTokens msPKIDPAPIMasterKeys msPKIRoamingTimeStamp msTPM-OwnerInformation msTPM-OwnerInformationTemp unixUserPassword (this value is not used or updated by Samba) The confidential attributes on your server can be seen (adapt for your local environment) with: ldbsearch -U$USERNAME -H ldap://$SERVER -b CN=Schema,CN=Configuration,$BASE_DN '(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=128))' lDAPDisplayName However, please again note that while unlikely, it is possible via the nTSecurityDescriptor for any attribute to be made access controlled on any object, and these cases will not be shown by this command. ================================== Limitations for indexed attributes ================================== Additionally, due to the nature of our object indexes, Samba must evaluate these prior to ACL checking, so read access controlled information should not be stored in indexed attributes. This will allow a timing attack. Again, taking each of the above classes in turn: - Secret attributes cannot be indexed or searched for, so have always been protected - Confidential attributes are further protected, as this patch will prevent attributes marked as 'confidential' from being indexed. Search results for these will be safer, but slower. The impacted attributes on your server can be seen (adapt for your local environment) with: ldbsearch -U$USERNAME -H ldap://$SERVER -b CN=Schema,CN=Configuration,$BASE_DN '(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=129))' lDAPDisplayName (This will normally return no results and no such attributes have this combination by default) - Access controlled attributes that are also indexed may be subject to timing attacks. The list of indexed attributes can be seen (adapt for your local environment) with: ldbsearch -U$USERNAME -H ldap://$SERVER -b CN=Schema,CN=Configuration,$BASE_DN '(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=1))' lDAPDisplayName ================== Performance impact ================== As candidate objects are ACL checked before being compared with the LDAP filter, avoiding this disclosure, Samba's AD DC LDAP read performance is reduced, with a 20% performance cost in the worst cases from our existing performance tests. Further optimisation of the Samba AD DC LDAP server to ameliorate this impact has been investigated and is technically possible, but is out of scope for this security release. ================== Patch Availability ================== Patches addressing both these issues have been posted to: https://www.samba.org/samba/security/ Additionally, Samba $VERSIONS 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:C/C:H/I:N/A:N (7.7) ========== Workaround ========== Do not store confidential information in Active Directory, other than passwords or keys required for AD operation (as these are in the hard-coded secret attribute list). ======= Credits ======= Originally reported by Demi Marie Obenour of Invisible Things Lab. Patches provided by Joseph Sutton of Catalyst and the Samba team, reviewed by Andrew Bartlett of Catalyst and the Samba Team. Advisory by Andrew Bartlett of Catalyst and the Samba Team in collaboration with Joseph Sutton and Demi Marie Obenour. ========================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ==========================================================