https://support.microsoft.com/en-us/topic/kb5020805-how-to-manage-kerberos-protocol-changes-related-to-cve-2022-37967-997e9acc-67c5-48e1-8d0d-190269bf4efb#thirdparty5020805 discloses a new Kerberos PAC buffer with a full-ticket signature.
This would appear to be important for securing the S4U2Proxy evidence ticket, as an attacker holding an account with the right to do constrained delegation could brute-force a HMAC-MD5 signature that matches the original but claims to be a privileged user, possibly by selecting it's own password carefully.
The new PAC buffer is over the entire PAC, and is aes256-cts-hmac-sha1-96 or aes128-cts-hmac-sha1-96 only, so there is no reliance on the server signature.
Created attachment 17643 [details]
Initial advisory without versions or CVE number
For those trying to work out what this new signature is and how it is calculated, a WIP branch is here:
The new signature will eventually be documented as an MS-KILE errata, but we have worked it out in the meantime, using tests against a patched Windows 2019 server.
What is a good base commit to review jsutton24/kdc-fixes?
Where exactly is the definition of the new KrbtgtFullPacSignature PAC buffer?
(In reply to nico from comment #4)
We have a thread with MS on cifs-protocol requesting this be documented.
C (in Heimdal) and Python implementations are here:
(In reply to nico from comment #3)
https://gitlab.com/samba-team/devel/lorikeet-heimdal/-/commits/lorikeet-heimdal-202210310104/ is the tree we imported and Samba master is based on. That in turn follows up to ed406301740877c99ee5f0f8b9b30dbb67ae2da7 in Heimdal, but do see our patches in-between.
https://twitter.com/SteveSyfuhs/status/1590087676992327681 suggests a disclosure date of Dec 2022 if not publicly disclosed earlier.
Created attachment 17647 [details]
Draft advisory without versions (v2)
Metze and I agreed that Samba will not do an incremental deployment of this feature. It will be on and required as soon as the update is deployed.
The impact (need to get a new TGT) is on users accessing services that use constrained delegation (S4U2Proxy), and those will users will experience a 'flag day', with all DCs required to be upgraded at near the same time.
This is because the evidence tickets they hold will not have the full signature on them. However such tickets are typically obtained just before access to a service (but can be cached) so as long as all DCs are upgraded at the same point, disruption will be somewhat limited.
The single-phase of deployment is due to resource and time constraints as we didn't get pre-disclosure of this issue.
Does AD still not support key history for principals?
What are the considerations around re-keying of manually-keyed cross-realm trust accounts?
For krbtgt/SOME-MIT-OR-HEIMDAL-REALM@SOME-AD-REALM you can just cpw/setkey on the principal on the MIT or Heimdal KDCs, wait for it to propagate, then change the password/key of that principal on the AD side.
For krbtgt/SOME-AD-REALM@SOME-MIT-OR-HEIMDAL-REALM, if AD still lacks key history, this is much harder, and requires first reducing the ticket lifetime of tickets issued for that service principal, then changing the keys on the AD and MIT or Heimdal sides at the same time, then restoring the long ticket lifetime setting after propagation. Is this still correct?
(In reply to nico from comment #9)
There is some support for re-key, less in Samba than in Windows AD (krbtgt key rollover in Samba can be disruptive), but comment #8 not not about changing keys or encryption types.
This bug is only about about adding in and enforcing the presence of the new PAC buffer ( KrbtgtFullPacSignature).
KrbtgtFullPacSignature is only in service tickets, so TGTs and trusts are not impacted, but a pre-update service ticket presented to Samba for constrained delegation will not be accepted.
Removing Samba-only CVE, Red Hat points to CVE counting rules that say for the
same issue in multiple products but following one specification, use one CVE,
so we will use the MS one.
Created attachment 17655 [details]
Updated v3 advisory with MS CVE
Created attachment 17672 [details]
Updated with clear documentation on the flag day.
The new smb.conf options and session key changes probably need documenting.
(In reply to Andrew Bartlett from comment #13)
Sorry, this is in bug 15237
This issue is now fully public with a paper published:
Opening these bugs to the public, and the core issue that triggered this is now described in a BlackHat Europe Presentation by Tom Tervoort, Principal Security Specialist at Secura.
Removing the embargo tag as the code and now a clear description is now public.
Created attachment 17685 [details]
This bug was referenced in samba master:
This bug was referenced in samba v4-15-test:
This bug was referenced in samba v4-16-test:
This bug was referenced in samba v4-17-test:
Created attachment 17702 [details]
This bug was referenced in samba v4-16-stable (Release samba-4.16.8):
This bug was referenced in samba v4-15-stable (Release samba-4.15.13):
This bug was referenced in samba v4-17-stable (Release samba-4.17.4):
I have an initial implementation of this for MIT krb5 at https://github.com/krb5/krb5/pull/1284 . Does the Samba team by chance have a captured DER-encoded service ticket with associated server and krbtgt key that I could use for testing?
(In reply to Greg Hudson from comment #27)
I have a captures with keytabs here:
This wireshark branch is also able to show which key
was used for the signature:
(In reply to Stefan Metzmacher from comment #28)
I guess w2022-l7.base-administrator-kinit-smbclient-w2022-118.w2022-l7.base-ok-01.* is what want to look at...
I don't see full checksums in either of the tickets issued in that trace, presumably because they are both TGTs.
(In reply to Greg Hudson from comment #30)
w2022-l7.base-administrator-kinit-smbclient-w2022-118.w2022-l7.base-ok-01.pcap.gz frame 161 (gets the ticket from the KDC) and frame 186 (uses it for SMB3 access)
Thanks; I had somehow downloaded the ub1404 failure trace thinking it was the w2022 base trace. I see a PAC with a full checksum in frame 161 of the correct trace.