CVE-2013-3900 WinVerifyTrust Signature Validation Vulnerability

From the official Microsoft Fix Action web site (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900), the registry value can be either DWORD or REG_SZ. However, I would personally choose DWORD over REG_SZ because the REG_SZ will need to be converted to DWORD by Windows when interpreting the value as a number.

For 32-bit versions of Windows, use the following text:

Windows Registry Editor Version 5.00 
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] 
"EnableCertPaddingCheck"=dword:1 

For 64-bit versions of Windows, use this text:

Windows Registry Editor Version 5.00 
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] 
"EnableCertPaddingCheck"=dword:1

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] 
"EnableCertPaddingCheck"=dword:1

Note You must restart the system for your changes to take effect. Impact of enabling the functionality change: Non-conforming binaries will appear unsigned and, therefore, be rendered untrusted.

Verifying that the Improvement to Authenticode Signature Verification is Implemented Correctly

Earlier versions of CVE-2013-3900 had recommended configuring EnableCertPaddingCheck to string value “1”, rather than to DWORD 1. Customers who had followed that guidance do not need to make further changes to their systems. Although Windows treats the EnableCertPaddingCheck value as a DWORD, its actual registry value type does not matter, as long as all these length and data requirements are met:

• The EnableCertPaddingCheck registry value is present (any data type)
• The value’s data length is from 1 to 4 bytes
• At least one of those bytes is a non-zero value

Compliance validation tools should not fail the EnableCertPaddingCheck inspection for its value type. Ideally, a test should read the value as a four-byte value, ignoring its type, and pass the test if the four-byte value is present and non-zero. If a scanning tool does not support specifying validation criteria that way, then given the two specific ways Microsoft has published to configure the setting, scanning tools should pass the check if either of these is true:

• EnableCertPaddingCheck is a REG_DWORD, value exactly "1"
• EnableCertPaddingCheck is a REG_SZ, value exactly "1"Impact of enabling the functionality change: Non-conforming binaries will appear unsigned and, therefore, be rendered untrusted. Verifying that the Improvement to Authenticode Signature Verification is Implemented Correctly Earlier versions of CVE-2013-3900 had recommended configuring EnableCertPaddingCheck to string value “1”, rather than to DWORD 1. Customers who had followed that guidance do not need to make further changes to their systems. Although Windows treats the EnableCertPaddingCheck value as a DWORD, its actual registry value type does not matter, as long as all these length and data requirements are met:
  • The EnableCertPaddingCheck registry value is present (any data type)
  • The value’s data length is from 1 to 4 bytes
  • At least one of those bytes is a non-zero value
  Compliance validation tools should not fail the EnableCertPaddingCheck inspection for its value type. Ideally, a test should read the value as a four-byte value, ignoring its type, and pass the test if the four-byte value is present and non-zero. If a scanning tool does not support specifying validation criteria that way, then given the two specific ways Microsoft has published to configure the setting, scanning tools should pass the check if either of these is true:
  • EnableCertPaddingCheck is a REG_DWORD, value exactly "1"
  • EnableCertPaddingCheck is a REG_SZ, value exactly "1"