The Samba-Bugzilla – Attachment 17688 Details for
Bug 15237
CVE-2022-37966 [SECURITY] arcfour-hmac-md5 Kerberos session keys are weak, force aes256-cts-hmac-sha1-96 instead
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
Advisory v5
CVE-2022-37966-avoid-arcfour-sessions-v5.txt (text/plain), 4.72 KB, created by
Andrew Bartlett
on 2022-12-13 02:50:21 UTC
(
hide
)
Description:
Advisory v5
Filename:
MIME Type:
Creator:
Andrew Bartlett
Created:
2022-12-13 02:50:21 UTC
Size:
4.72 KB
patch
obsolete
>=========================================================== >== Subject: rc4-hmac Kerberos session keys issued >== to modern servers >== >== CVE ID#: CVE-2022-37966 >== >== Versions: All versions of the Samba AD DC >== >== Summary: This is the Samba CVE for the Windows Kerberos >== RC4-HMAC Elevation of Privilege Vulnerability >== disclosed by Microsoft on Nov 8 2022. >== >== A Samba Active Directory DC will issue weak rc4-hmac >== session keys for use between modern clients and servers >== despite all modern Kerberos implementations supporting >== the aes256-cts-hmac-sha1-96 cipher. >=========================================================== > >=========== >Description >=========== > >Kerberos, the trusted third party authentication system at the heart >of Active Directory, issues a session key known to the target server >and the client, encrypted to both services in a TGS-REP. > >The key algorithm chosen for here is then used for the subsequent >signed or encrypted connection (eg GSSAPI secured LDAP or DCE/RPC). > >The kerberos rc4-hmac (also known as arcfour-hmac-md5) cipher is weak, >as the checksum is calculated as HMAC-MD5(MD5(DATA), KEY) meaning that >an active attacker knowing the plaintext data could create a different >chosen DATA, with the same MD5 checksum, and substitute it into an >signed but un-encrypted data stream without being detected. >(Encrypted connections, which are more typical, are not impacted). > >Because of the earlier MD5 step, the protection of the HMAC is >bypassed and an attacker does not need to know the key. > >For successful communication, the session key key needs to be of a >type understood by all parties. > >Traditionally it was assumed that the administrator would provision >the strongest long term key possible for the software on the Kerberos >target, so this long-term key list was also used as the set of >possible session keys. > >This is a reasonable assumption where regular updates to >msDS-SupportedEncryptionTypes are made, however if this is not >updated, the default has been the rc4-hmac (arcfour-hmac-md5) cipher >introduced in Active Directory in Windows 2000. > >It is not possible to, without specific testing, update >msDS-SupportedEncryptionTypes to include the AES cipher bits >arbitrarily (the target may not have AES keys in the keytab, or may >have the wrong salt), but it is reasonable in 2022 to assert that all >Kerberos clients understand the aes256-cts-hmac-sha1-96 cipher. > >After this update, the default for an unspecified >msDS-SupportedEncryptionTypes becomes based on an smb.conf option >"default domain supported enctypes", and this is set by default to >"arc4-hmac, aes256-cts-hmac-sha1-96-sk". > >aes256-cts-hmac-sha1-96-sk is a non-IETF keytype name with the >behaviour that regardless of the ticket key encryption type selected >(for example rc4-hmac, being the insecure algorithm being avoided, >Samba does not support DES), that aes128-cts-hmac-sha1-96 and >aes256-cts-hmac-sha1-96 session keys can still be negotiated. > >However, the ticket itself will still be encrypted with rc4-hmac. The >preferred solution is in the Workaround below. > >================== >Patch Availability >================== > >Patches addressing both these issues have been posted to: > > https://www.samba.org/samba/security/ > >Additionally, Samba $VERSIONS have been issued >as security releases to correct the defect. Samba administrators are >advised to upgrade to these releases or apply the patch as soon >as possible. > >================== >CVSSv3 calculation >================== > >CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1) > >It is noted that this score matches Microsoft's for the same issue. > >Despite this value, please note that this attack requires: > * that the connection not be encrypted, only signed > * that an active attacker obtains a plaintext value of the packet > * and can find another plaintext value with the same MD5 checksum and > replace it undetected. > >============================ >Workaround and long-term fix >============================ > >After confirming a valid key of aes256-cts-hmac-sha1-96 is present in >the target service keytab setting msDS-SupportedEncryptionTypes to >(base 10) 16 on that service's account in LDAP will avoid using >rc4-hmac entirely. AES256 support can also be set in Active Directory >Users and computers. > >======= >Credits >======= > >Originally reported to Microsoft by Tom Tervoort with Secura >https://www.secura.com/ and released as CVE-2022-37966. > >Advisory written by Andrew Bartlett of Catalyst and the Samba Team. > >Patches provided by Joseph Sutton of Catalyst and the Samba Team. > >========================================================== >== Our Code, Our Bugs, Our Responsibility. >== The Samba Team >========================================================== >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 15237
:
17648
|
17656
|
17686
|
17687
|
17688
|
17695
|
17696
|
17697
|
17699
|
17704
|
17706