Red Hat Enterprise Linux and Microsoft security update of November 2022

On November 8th, 2022, Microsoft released a series of security updates for various Windows operating systems to fix two security issues:

• CVE-2022-37966, knowledge base article
• CVE-2022-37967, knowledge base article

Both security issues aren’t documented in detail. The security advisories talk about “Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability” and a generic “Windows Kerberos Elevation of Privilege Vulnerability,” correspondingly. From the accompanying knowledge base articles we can see that these vulnerabilities affect use of the standard RC4-HMAC encryption type in the Active Directory Kerberos implementation. It has been known for some time that RC4-HMAC is an encryption type that might be broken, and a recommendation has been to disable RC4-HMAC use in Active Directory environment, enforced via various STIG and CIS profiles for Windows systems.

This article outlines how Microsoft’s November 2022 security release for Active Directory vulnerabilities affects RHEL-based solutions. In order to do so, we need to dive deeper into what the Microsoft security release is attempting to fix, based on the incomplete information we have so far.

Active Directory Kerberos implementation

As described by Microsoft, Active Directory implementation provides a number of compatibility features that allow it to migrate from older Windows solutions. While neither Windows NT nor initial Active Directory versions through Windows Server 2008 are supported any more, even Windows Server 2022 contains the compatibility features that allow users to migrate from Windows NT domains without changing their passwords. The original passwords were encrypted with an algorithm that directly translates to Kerberos RC4-HMAC encryption type.

When Active Directory is deployed, one first installs a standalone Windows server. The standalone server defaults to use the same method for encrypted passwords that is directly translated to Kerberos RC4-HMAC encryption type. Deployment of the Active Directory domain controller on the standalone Windows server would then extend a list of supported encryption types for Kerberos keys in Active Directory. However, RC4-HMAC keys would still be present for the principals created prior to the Active Directory deployment (for example, Administrator) and for the primary Kerberos realm principal, krbtgt/REALM@REALM prior to application of the enforcing group policy.

In order to maintain compatibility to older releases, Microsoft Active Directory domain controllers follow a complex logic when choosing a particular encryption type for a key generated for a particular Kerberos ticket. The choice is not only dependent on an availability of common key types for both the Kerberos client and the Kerberos service principals, in some cases RC4-HMAC is used even when AES session keys are available. This is especially true for the cases when Kerberos service principals were created during the Active Directory deployment, when enforcement of more secure encryption types was not yet in place.

CVE-2022-37966 and CVE-2022-37967 security advisories hint that there are situations where an attacker might be able to affect Kerberos tickets which use RC4-HMAC keys. How this is accomplished is not entirely clear. What matters is that an attack is at least theoretically possible and the Microsoft team responsible for Active Directory Kerberos implementation finally decided to push through the removal of RC4-HMAC keys from any on-wire operations – not only in Kerberos itself but also in a Netlogon operations, essential to communication in an Active Directory domains between the enrolled Windows clients and domain controllers. This scope hints that some of the ticket payload might be affected and its validation might be under an attacker control, hence "elevation of privilege vulnerability".

AES encryption enforcement in Active Directory as of November 2022

Unfortunately, a laudable attempt to improve the security of Kerberos operations in Active Directory was spoiled by a bug in the code fixing this issue. When RC4 usage is already disabled in the Active Directory deployment, the code does not understand it and rejects all-AES communication as well. As Steve Syfuhs, a developer at Microsoft, said on Twitter:

“The issue is the absence of RC4 in the list. If that bit is not set, things fall back to a weird state. If only AES bits are set, that weird state conflicts with 'AES only’.”

The issue is now acknowledged by Microsoft and a fix would be published in upcoming weeks. This means the November 8, 2022 security update is not yet compatible with systems that already do not use RC4 cipher. This includes both Windows and Linux systems, as a faulty Active Directory domain controller would reject a request coming from an enrolled RHEL system similarly how it would reject a request from a Windows machine enrolled into the same domain. Red Hat has issued a small knowledgebase article about this. The article recommends making your Microsoft support partner aware your deployment is affected and get notified when the fix is available.

Open source activities

Further securing communications between Microsoft Active Directory and compatible open source solutions is an important effort. With the release of RHEL 9.0 earlier this year, Red Hat has already tightened up many defaults of the operating system, including disabling or removing some old cipher suites. For example, RC4-HMAC is not enabled by default in RHEL 9.0 and is not used by the RHEL IdM. Kerberos encryption types using SHA-1 algorithm to calculate a checksum were also disabled by default. RHEL IdM defaults use more secure variants of AES encryption types in its Kerberos implementation. This change also means there are no common encryption types for Active Directory interoperability because Active Directory does not support SHA-2-based algorithms for the checksums in Kerberos encryption types, as defined in RFC 8009.

In order to retain the compatibility with Active Directory, RHEL 9 provides several cryptographic subpolicies which enable older cipher sets: AD-SUPPORT, AD-SUPPORT-LEGACY, and SHA1. The AD-SUPPORT subpolicy allows use of AES-based encryption types which use SHA-1 algorithm for its checksum. The AD-SUPPORT-LEGACY subpolicy on top of that adds use of RC4-HMAC encryption type. Finally, the SHA1 subpolicy allows SHA1 use separately from Kerberos encryption types. This is useful when smartcards are enabled on the Active Directory side as SHA-1 checksum is still used in the PKINIT Kerberos protocol extension.

For many of these improvements to be useful without enabling legacy or weaker ciphers, we need updates to corresponding RFCs and to Kerberos implementations (MIT Kerberos, Heimdal, …) as well as Microsoft’s Active Directory. Use of AES encryption types with SHA-2 HMAC algorithms defined in RFC 8009 is one of the most obvious changes that would improve security.

Support for November 2022 security enhancements

While Microsoft’s November 2022 security enhancements had an interoperability issue in the implementation, they were still a good move. Once the bug in initial implementation is fixed, another interoperability trip needs to be performed, this time by the open source projects. Samba Team developers are working together with Microsoft’s documentation team to make sure corresponding specifications get updated. Updates are available only for one part of the security fix right now: an enforcement of the AES-based session key in Kerberos communications as a separate encryption key type. Details of the other changes, to add an additional checksum in the privilege attribute certificate structure of the Kerberos service ticket (PAC) and improvements in DCE RPC protocols, have not been published so far.

Once all the specifications are available, the open source community can add support for them to MIT Kerberos, Heimdal, Samba and FreeIPA. Hopefully, this happens before enforcement deadlines Microsoft has outlined in the original security bulletin. Linux distributions would then get those changes delivered to their users. Hopefully, this will happen more quickly, but that entirely depends on the collaboration between multiple vendors. For the past decade we have been enjoying a productive interaction with Microsoft as well and hope this joint effort to improve security of the enterprise infrastructure landscape continues onward.