Confidential attribute disclosure from the AD LDAP

Description

All versions of the Samba Active Directory LDAP server from 4.0.0
onwards are vulnerable to the disclosure of confidential attribute
values, both of attributes where the schema SEARCH_FLAG_CONFIDENTIAL
(0x80) searchFlags bit and where an explicit Access Control Entry has
been specified on the ntSecurityDescriptor.

The confidential attribute disclosure is via the search expression and
can be seen by the return (or failure to return) matching LDAP
objects.

This issue does NOT apply to secret attributes such as unicodePwd.
These values have always been prohibited in LDAP search expressions.
(Additionally since Samba 4.8 they remain encrypted at search
expression processing time).

The following attributes in the 2008R2 AD schema have
SEARCH_FLAG_CONFIDENTIAL set in the searchFlags by default:

unixUserPassword, msFVE-KeyPackage, msFVE-RecoveryPassword,
msPKIAccountCredentials, msPKIAccountCredentials,
msPKI-CredentialRoamingTokens, msPKIDPAPIMasterKeys,
msPKIRoamingTimeStamp, msTPM-OwnerInformation

For clarity: unixUserPassword is NOT populated by Samba.

Remaining issues

Samba makes no attempt to address possible timing attacks against the
LDAP server. Data (aside from secret attributes, already subject to
special processing) of such a sensitivity such that a timing attack
would be worthwhile should not be stored in Active Directory.

Patch Availability

A patch addressing this defect has been posted to

http://www.samba.org/samba/security/

Additionally, Samba 4.8.4, Samba 4.7.9 and 4.6.16 have been issued as
a security release to correct the defect. Patches against older Samba
versions are available at http://samba.org/samba/patches/. Samba
vendors and administrators running affected versions are advised to
upgrade or apply the patch as soon as possible.

Workarounds and Mitigation

The only workaround is not to use the SEARCH_FLAG_CONFIDENTIAL
searchFlags bit, not to expect confidentiality of the attribute list
above nor to set access control entries of a similar nature on LDAP
objects.

Credits

The issue was reported by Phillip Kuhrt. Tim Beale of Catalyst
provided the test and patches.