Bug 13595 (CVE-2018-14628) - CVE-2018-14628 [SECURITY] Deleted Object tombstones visible in AD LDAP to normal users
Summary: CVE-2018-14628 [SECURITY] Deleted Object tombstones visible in AD LDAP to nor...
Alias: CVE-2018-14628
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.14.6
Hardware: All All
: P5 critical (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Blocks: 14079 15244
  Show dependency treegraph
Reported: 2018-08-31 01:27 UTC by Andrew Bartlett
Modified: 2023-03-30 07:35 UTC (History)
5 users (show)

See Also:

Inital CVE text (2.21 KB, text/plain)
2018-08-31 01:27 UTC, Andrew Bartlett
no flags Details
Complete CVE (2.21 KB, text/plain)
2018-09-05 01:20 UTC, Aaron Haslett (dead mail address)
no flags Details
WIP patches for master (10.17 KB, patch)
2021-10-19 15:17 UTC, Stefan Metzmacher
metze: review? (abartlet)

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Bartlett 2018-08-31 01:27:47 UTC
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.
Comment 1 Andrew Bartlett 2018-08-31 01:32:44 UTC
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.
Comment 2 Aaron Haslett (dead mail address) 2018-09-05 01:20:11 UTC
Created attachment 14477 [details]
Complete CVE
Comment 3 Andrew Bartlett 2019-12-17 02:00:18 UTC
This article is relevant:


I can't see the ntsecuritydescriptor of cn=deleted objects over LDAP, so we may have the wrong one.
Comment 4 Andrew Bartlett 2020-02-25 21:53:53 UTC
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.
Comment 5 Stefan Metzmacher 2021-10-19 13:54:51 UTC
(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/
Comment 6 Stefan Metzmacher 2021-10-19 15:17:57 UTC
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...
Comment 7 Andrew Bartlett 2021-10-19 17:25:04 UTC
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.
Comment 8 Stefan Metzmacher 2021-10-20 10:15:59 UTC
(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).
Comment 9 Andrew Bartlett 2022-04-13 03:37:53 UTC
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.
Comment 10 Andrew Bartlett 2022-06-13 09:10:57 UTC
Putting back CVE, I was mistaken.  It was a similar but not identical CVE used by someone else.
Comment 11 Michael Tokarev 2023-03-30 07:34:43 UTC
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?