Windows: Credential Guard Non-Constant Time Comparison Information Disclosure Platform: Windows 10+ Class: Information Disclosure Security Boundary: Virtual Secure Mode Summary: The handling of cryptographic data comparison in the CG secure process doesn't use constant time algorithms resulting in information disclosure. Description: The CG RPC APIs contain a number of functions which take an encrypted blob of some kind and compare it to another value provided by the user. For example the NtlmIumComparePasswordToProtectedPassword API compares an encrypted LSAISO password to a plain text password and returns a true value if the decrypted password is a match. The implementation of NtlmIumComparePasswordToProtectedPassword calls RtlEqualUnicodeString (well actually via a thin wrapper) to compare the decrypted password to the plain text password. This API is _NOT_ constant time, it does character by character comparison and exits at the first non-matching character. This is a classic example of a timing attack against a cryptographic system. Some other APIs are KerbIumAreEncryptedBuffersEqual which basically compares two encrypted passwords again with RtlEqualUnicodeString and KerbIumAreEncryptionKeysEqual which compares encrypted keys. In this case it uses RtlCompareMemory which is not constant time but realistically would be hard to exploit due to using optimized comparison operations. There are probably other APIs I'm missing. Such comparisons should realistically be replaced with constant time equivalents so that they can't be exploited to disclose encrypted data through timing attacks. The password APIs using RtlEqualUnicodeString are especially worrisome. How practical they are to attack in reality is another matter. Proof of Concept: I've not provided any PoC for these issues. However I've verified that the comparisons used by the described functions are not constant time. This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2022-08-25. Related CVE Numbers: CVE-2022-34704,CVE-2022-34704. Found by: forshaw@google.com