Bug 14703 - [SECURITY] We should harden the rodc_join / LDAP_SERVER_RODC_DCPROMO_OID
Summary: [SECURITY] We should harden the rodc_join / LDAP_SERVER_RODC_DCPROMO_OID
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.14.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Jo Sutton
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: CVE-2020-25722
  Show dependency treegraph
 
Reported: 2021-05-13 02:55 UTC by Andrew Bartlett
Modified: 2021-11-22 09:46 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Bartlett 2021-05-13 02:55:40 UTC
Samba allows creation of RODC krbtgt accounts (eg accounts with msDS-SecondaryKrbTgtNumber set) as a normal user, provided that user has write privileges in the OU in which it is created.

The Full DC's KDC will attempt to accept such tickets. 

However, thankfully the password that is set on the account is randomly re-generated (thanks metze!) so this is of little security consequence. 

MS-ADTS 3.1.1.5.3.2 Constraints applies to modifications, so an existing account can't become an RODC (with a known password) because msDS-SecondaryKrbTgtNumber is SystemOnly and has schema constraints: 

We don't need to lock down uniqueness or otherwise direct add/modify of this attribute, this is already done via the rangeLower and rangeUpper values on the schema (when the control is specified this is bypassed with LDB_FLAG_INTERNAL_DISABLE_VALIDATION), but a test should be written to ensure this stays that way.

However, MS-ADTS 3.1.1.3.4.1.23 LDAP_SERVER_RODC_DCPROMO_OID https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1565620e-d72c-4a8c-95fc-570e0d275639 says this control should be restricted to users with the DS-Install-Replica control access right.

This embargoed bug added in case I've missed something, and will be opened up later once we are really sure this is locked down properly.
Comment 1 Andrew Bartlett 2021-05-13 04:11:08 UTC
We wont be requesting a CVE or issuing a security release.  The privileged user who can add such accounts could exhaust the KVNO pool (16 bits) but they would own the objects involved and so could be located and dealt with at a higher protocol layer.

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H (4.9) at worst, but this would only stop building a new RODC, so more likely CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L (2.9).
Comment 2 Andrew Bartlett 2021-05-13 09:21:51 UTC
TODO: confirm that the value 65536 is not a bypass for the rangeUpper/rangeLower trick preventing setting during add.
Comment 3 Andrew Bartlett 2021-06-23 23:44:54 UTC
(In reply to Andrew Bartlett from comment #2)
65536 is such a bypass.  Also sequencing may be possible to allow such accounts to be replicated, eg to another RODC.  We should harden creation and also strictly enforce a link to an account with UF_PARTIAL_SECRETS to check the allowed rodc replication stuff.
Comment 4 Andrew Bartlett 2021-06-23 23:49:46 UTC
(In reply to Andrew Bartlett from comment #3)
The sequencing I refer to is creating the account, but not adding the msDS-krbTgtLink until after the password is replicated to a different RODC.  This would allow that other RODC to obtain the password and print tickets with the new account, without leaving it's own fingerprints on it.

Strictly testing the target of the krbTgtLink would ensure that a privileged user created the target, but we should just ban setting msDS-SecondaryKrbTgtNumber specifically.
Comment 5 Andrew Bartlett 2021-10-18 16:57:27 UTC
A top level bug 14564 / CVE-2020-25722 will be used for these related issues.
Comment 6 Samba QA Contact 2021-11-09 18:18:29 UTC
This bug was referenced in samba v4-14-stable (Release samba-4.14.10):

6bdda2d93ed49a07014a132a83f3a63efb332387
7bd4145daa716b443d3e1f46a2627c26a3ddeab2
e90034d9182cd5936f92d70ab3804df8ec260d63
762ef653b9dabd0f1dd565444d05b709e0d32c32
Comment 7 Samba QA Contact 2021-11-09 18:22:11 UTC
This bug was referenced in samba v4-15-stable (Release samba-4.15.2):

65973d2efd4b27d564cb673bb6d349e8b5e0527e
b02578014f7ef9d8f59cafa9b62c2a6696c03270
07aef1e648d0b7464739647063ccb207061674d4
53de95a1f6a4a591c1bd8e470f39ecd34ac59099
Comment 8 Samba QA Contact 2021-11-09 18:24:18 UTC
This bug was referenced in samba v4-13-stable (Release samba-4.13.14):

d82cba0d8c796a140c52da72f5cbf10ca0e1de5a
0c20aa465c4543055fcb38d3e28cefb9ee603f87
448585950bda2c1daab8ffeb3971870ed0416634
20e466c13690600519511e45b0c72ed7987d2575
Comment 9 Samba QA Contact 2021-11-09 18:41:59 UTC
This bug was referenced in samba v4-15-test:

65973d2efd4b27d564cb673bb6d349e8b5e0527e
b02578014f7ef9d8f59cafa9b62c2a6696c03270
07aef1e648d0b7464739647063ccb207061674d4
53de95a1f6a4a591c1bd8e470f39ecd34ac59099
Comment 10 Samba QA Contact 2021-11-09 18:47:48 UTC
This bug was referenced in samba v4-13-test:

d82cba0d8c796a140c52da72f5cbf10ca0e1de5a
0c20aa465c4543055fcb38d3e28cefb9ee603f87
448585950bda2c1daab8ffeb3971870ed0416634
20e466c13690600519511e45b0c72ed7987d2575
Comment 11 Samba QA Contact 2021-11-09 19:17:56 UTC
This bug was referenced in samba v4-14-test:

6bdda2d93ed49a07014a132a83f3a63efb332387
7bd4145daa716b443d3e1f46a2627c26a3ddeab2
e90034d9182cd5936f92d70ab3804df8ec260d63
762ef653b9dabd0f1dd565444d05b709e0d32c32
Comment 12 Samba QA Contact 2021-11-09 20:39:25 UTC
This bug was referenced in samba master:

93e5902369c22d625fa2e48b3eafe043dc17e3ba
9ef9746bca73a939ad04b1df07caeb70921bc3de
f478aecc45efb56868bc7cec216f33e5db7ccf18
2bdff65b333365740e5e9c8c2b2fc176323f5108
Comment 13 Andrew Bartlett 2021-11-22 09:46:28 UTC
Removing embargo, adding [SECURITY] tag as we did end up marking this bug on some of the security fixes.  More could be done, but the most essential part is done.