Created attachment 14456 [details] Inital CVE text Samba's AD DC shows deleted objects to all users, not just administrators (tested against Windows 1709). (Sadly I can't find a more precise definition of what the access control rule should be.) CVSSv3: https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (4.3) My new practice is to write the CVE and do the CVSS at the earliest opportunity, so we can prioritise this correctly, and consider carefully if we really need to do the full CVE thing.
Steps to reproduce: samba-tool user add fred -H ldap://$SERVER -Uadministrator samba-tool user delete fred -H ldap://$SERVER -Uadministrator samba-tool user add unpriv -H ldap://$SERVER -Uadministrator ldbsearch -H ldap://$SERVER -Uadministrator --show-deleted '(&(objectclass=*)(isdeleted=TRUE))' ldbsearch -H ldap://$SERVER -Uunpriv --show-deleted '(&(objectclass=*)(isdeleted=TRUE))' Against Samba, the two searches give the same results, against Windows the deleted user 'fred' is missing.
Created attachment 14477 [details] Complete CVE
This article is relevant: https://support.microsoft.com/en-us/help/892806/how-to-let-non-administrators-view-the-active-directory-deleted-object I can't see the ntsecuritydescriptor of cn=deleted objects over LDAP, so we may have the wrong one.
Microsoft confirms that the only protection against seeing deleted objects is the ACL on the CN=Deleted Objects container, which is missing in Samba-originating provisions.
(In reply to Andrew Bartlett from comment #3) The ACL is available via drsuapi, samba-tool drs clone-dc-database should reveal it when looking at the files under sam.ldb.d/
Created attachment 16855 [details] WIP patches for master I actually found fixes for this..., but I wasn't aware of the security impact and forgot about them, they have been part of my public wip branches for years...
Thanks. Do you think we should still do a security release for this? Also, to remind ourselves, for this fix we will need to update the CVE text to tell folks they have to dbcheck --reset-well-known-acls run after the patch is applied, which will wipe out any custom changes they made to those. We should prepare a separate LDIF snippet to apply just this fix. We also need a simple smoke test.
(In reply to Andrew Bartlett from comment #7) I'm not sure about a security release... Maybe we can have a dbcheck option that just resets the deleted object ACL... instead of a full --reset-well-known-acls (but that would also imply the new option).
Removing CVE as this CVE has been used by someone else. Given feedback and public patches, removing embargo, it is actively preventing this issue being fixed by imposing extra workload.
Putting back CVE, I was mistaken. It was a similar but not identical CVE used by someone else.
So, what's the status of this change? Maybe we can start from using correct ACLs for new installs, and provide a script fixing the ACL for existing installs later?