Attachment 17706 Details for Bug 15237 – CVE-2022-37966-avoid-arcfour-sessions-v7-ready.txt

CVE-2022-37966-avoid-arcfour-sessions-v7-ready.txt

CVE-2022-37966-avoid-arcfour-sessions-v7-ready.txt (text/plain), 6.68 KB, created by Jule Anger on 2022-12-15 15:02:52 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jule Anger

Created: 2022-12-15 15:02:52 UTC

Size: 6.68 KB

patch

obsolete

>===========================================================
>== Subject:     rc4-hmac Kerberos session keys issued
>==              to modern servers
>==
>== CVE ID#:     CVE-2022-37966
>==
>== Versions:    All versions of Samba using Kerberos
>==
>== 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.
>==
>==              On Samba Active Directory DCs and members
>==              'kerberos encryption types = legacy' would force
>==              rc4-hmac as a client even if the server supports
>==              aes128-cts-hmac-sha1-96 and/or aes256-cts-hmac-sha1-96.
>===========================================================
>
>===========
>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 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 client and server software support the aes256-cts-hmac-sha1-96 cipher.
>
>After this update, the fallback for an unspecified
>msDS-SupportedEncryptionTypes (either no value or explicit "0")
>becomes "rc4-hmac, aes256-cts-hmac-sha1-96-sk" by default.
>The fallback value can be controlled by the
>"kdc default domain supported enctypes" smb.conf option if required.
>
>aes256-cts-hmac-sha1-96-sk (bit 0x20 in msDS-SupportedEncryptionTypes)
>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.
>
>Note that after this update, the fallback for an unspecified
>msDS-SupportedEncryptionTypes (either no value or explicit "0")
>for trustedDomain objects are changed in an incompatible way!
>The fallback is now aes256-cts-hmac-sha1-96 instead of 
>rc4-hmac! It is therefor recommended to explicitly set the value
>on both sides of the trust before or immediately after the
>update. See more details in the Workaround below.
>
>==================
>Patch Availability
>==================
>
>Patches addressing both these issues have been posted to:
>
>    https://www.samba.org/samba/security/
>
>Additionally, Samba 4.15.13, 4.16.8 and 4.17.4 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.
>
>In some situations winbindd (as AD DC or AD domain member),
>as well as tools like 'net' generate/use a custom krb5.conf file.
>Using the option "kerberos encryption types = legacy" will
>force rc4-hmac and disable aes128-cts-hmac-sha1-96 and
>aes256-cts-hmac-sha1-96 support. In 2022 there's no longer 
>any reason to use "kerberos encryption types = legacy"!
>Also inspect your global /etc/krb5.conf and make sure it
>doesn't disable aes256-cts-hmac-sha1-96.
>
>For trusted domains you should explicitly configure the
>use of aes256-cts-hmac-sha1-96 support, either via the Windows GUI or
>the newly added 'samba-tool domain trust modify --use-aes-keys'.
>For legacy trusts against Windows 2000/2003 domains you need to force
>rc4-hmac using 'samba-tool domain trust modify --no-aes-keys'.
>Against remote DCs (including Windows) you can use the --local-dc-ipaddress=
>and other --local-dc-* options. See 'samba-tool domain trust modify --help'
>for further details.
>Note that already cached rc4-hmac cross-realm tickets may no longer
>work after switching to aes, which may cause temporary problems.
>Setting a 1 hour ticket lifetime may reduce the problems:
>  kdc:user_ticket_lifetime = 1
>
>=======
>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
>==========================================================
>

Flags:

slow: review+

Actions: View

Attachments on bug 15237: 17648 | 17656 | 17686 | 17687 | 17688 | 17695 | 17696 | 17697 | 17699 | 17704 | 17706