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?
This bug was referenced in samba master: 3be190dcf7153e479383f7f3d29ddca43fe121b8 0c329a0fda37d87ed737e4b579b6d04ec907604c 7f8b15faa76d05023c987fac2c4c31f9ac61bb47 498542be0bbf4f26558573c1f87b77b8e3509371 70586061128f90afa33f25e104d4570a1cf778db 97e4aab1a6e2feda7c6c6fdeaa7c3e1818c55566
Created attachment 18160 [details] Patches for v4-19-test
Created attachment 18161 [details] Patches for v4-18-test
Assigning to Jule for the next 4.19 and 4.18 releases.
Created attachment 18166 [details] CVE-2018-14628-metze-v1.txt Jule, at least the "Action required in order to resolve CVE-2018-14628!" section needs to be part of the next release notes!
Created attachment 18167 [details] CVE-2018-14628-metze-v2.txt
Created attachment 18168 [details] Patches for v4-17-test I think it would be useful to include this also in the next 4.17 security release...
Comment on attachment 18168 [details] Patches for v4-17-test +1 based on seeing six patches and six times cherry-picked.
Pushed to autobuild-v4-{19,18}-test. I will add the section to the release notes and I will include the bug for the next 4.17 security release.
This bug was referenced in samba v4-19-test: 427054ab1ba6b8798040123fa92aff6fe73fbd93 10673100a1be03f7c34befe7a8f2b3bd2d2d50af 31e4015b78e4e6ce1f83cc556febb4394bb8ef78 0e657c31ac90687f95391c31880564a909792264 98d0fa6c37db90c0cd4a319e3f5b80fe8b91c618 a72c72287301d66a5e1c11b30f5fb1e897341414
This bug was referenced in samba v4-18-test: e884fc791e59bd6ebd41b4a2ab7c9d7dc45415f4 46a168c9a89e82ccaf8d27669d1ae5459f7becb9 74a508b39e6fd5036a2adc99d559bd3852f8ce8d edac27f5408191567233983562091484ebbbad0a f967b91da76f86a9feb4c1469fccfce93be8bc79 cbbfc917b9635bc62825ea64a157028297f54fb7
This bug was referenced in samba v4-19-stable (Release samba-4.19.3): 427054ab1ba6b8798040123fa92aff6fe73fbd93 10673100a1be03f7c34befe7a8f2b3bd2d2d50af 31e4015b78e4e6ce1f83cc556febb4394bb8ef78 0e657c31ac90687f95391c31880564a909792264 98d0fa6c37db90c0cd4a319e3f5b80fe8b91c618 a72c72287301d66a5e1c11b30f5fb1e897341414
This bug was referenced in samba v4-18-stable (Release samba-4.18.9): e884fc791e59bd6ebd41b4a2ab7c9d7dc45415f4 46a168c9a89e82ccaf8d27669d1ae5459f7becb9 74a508b39e6fd5036a2adc99d559bd3852f8ce8d edac27f5408191567233983562091484ebbbad0a f967b91da76f86a9feb4c1469fccfce93be8bc79 cbbfc917b9635bc62825ea64a157028297f54fb7
With today's release of Samba 4.20.0, Samba 4.17 is end of life. There will therefore be no further 4.17 release, so I am closing the bug report.