Enable Certificate Padding Check: REG_SZ or REG_DWORD?

6 min readDec 23, 2024

Summary

To mitigate CVE-2013–3900, one must configure one or two EnableCertPaddingCheck registry values. Should the value type be REG_SZ or REG_DWORD? Answer: either will work, but REG_DWORD is the more manageable, intuitive, and preferable choice.

History

In security bulletin MS13–098 way back in December 2013, Microsoft announced CVE-2013–3900, a critical, remote-code-execution vulnerability on all supported Windows versions that could exploit a weakness in how the WinVerifyTrust API validated digital signatures on Portable Execution (PE) files such as EXEs and DLLs. The vulnerability made it possible to insert malicious code into unused padding space in the signature block of a signed executable without invalidating the signature. (Note that a successful exploit would require that the signed executable be designed to execute code in its signature block, which legitimate programs don’t do.)

Applying the fix in MS13–098 made Windows’ signature validation more rigorous, and some files’ signatures that had been valid no longer were. In particular, some legitimate vendors had used the extra padding space as an area to write customized content into executable files after installation without breaking the files’ signatures.

Back then, customers could choose which security vulnerabilities to patch and which to keep unpatched. (Today, Patch Tuesday security patches are delivered only through all-or-none monthly cumulative updates.) Microsoft released six separate patches for Windows vulnerabilities in December 2013; a customer could, for example, choose to apply the other five but not to apply MS13–098. Along with that patch, Microsoft announced that the stricter validation would become the default Windows behavior by August 2014. However, as customers reported compatibility issues with existing software, in July 2014 Microsoft reimplemented the fix as an opt-in configured with a registry value, rather than the default Windows behavior. It has remained that way to this day.

Microsoft Security Advisory 2915720 documented how to opt in to the stricter validation behavior, and how to revert that opt-in. To opt in, it advised creating and importing a regfile (“Registration Entries”, .reg extension) that would create a REG_SZ value called EnableCertPaddingCheck with the string value “1” (in one key on 32-bit Windows, and in two separate keys on 64-bit Windows to support both 64-bit and WOW64 processes). To undo that opt-in, it advised creating and importing a regfile that would delete the EnableCertPaddingCheck value(s).

In January 2022, the Microsoft Security Response Center (MSRC) republished CVE-2013–3900 in the Security Update Guide to inform customers that the EnableCertPaddingCheck opt-in fix is also applicable to and available for all supported Windows 10 and Windows 11 versions. That new article also repeated the regfile mechanisms to create and delete the REG_SZ values.

Because system administration is far more manageable (and thus preferable) with Group Policy than with regfiles, the Security Compliance Toolkit published an update to its “MS Security Guide” administrative template that added an “Enable Certificate Padding” setting to configure the necessary EnableCertPaddingCheck values. Having been advised by the Windows team that it would also work to configure EnableCertPaddingCheck as a REG_DWORD value (non-zero to opt in, zero to opt out), the Security Compliance Toolkit team published its administrative template that way.

The Center for Internet Security (CIS) subsequently determined that opting in to stricter signature validation met all its criteria for inclusion in its Level 1 Profile in the Microsoft Windows OS benchmarks. As system administrators themselves, the CIS benchmark stakeholders always favor Group Policy over regfiles, so the CIS Windows benchmarks make use of the MS Security Guide administrative template, and the GPOs and other artifacts CIS publishes thus configure the EnableCertPaddingCheck values as DWORD value 1.

Based on Microsoft’s documentation, some compliance scanning tools had reported a compliance failure if the EnableCertPaddingCheck registry type were anything other than REG_SZ, even though Microsoft’s best mechanism for configuring the setting sets a REG_DWORD. Numerous customers that rely on CIS benchmarks have since opened support tickets with scanning tool vendors.

In response to queries, MSRC updated its article in April 2024 to reaffirm that the value must be a REG_SZ and not a REG_DWORD. After further discussions, Microsoft updated the CVE in November 2024 to assert that the value needed to be a REG_DWORD and not a string. As a result, some compliance scanning tools now report a compliance failure if the value is configured as a REG_SZ. Finally, in December 2024, Microsoft updated its documentation based on the information below to clarify that either REG_SZ or REG_DWORD can achieve the desired results.

How does WinVerifyTrust interpret EnableCertPaddingCheck?

I performed extensive testing, setting EnableCertPaddingCheck to a variety of value types (including REG_BINARY and REG_NONE in addition to REG_SZ and REG_DWORD), value lengths, and value data, while performing signature validation tests with a signed executable in which I had modified the extraneous padding area that the default WinVerifyTrust behavior ignores. Windows reported the signature as valid when the stricter behavior was not enabled, and as invalid when the stricter behavior was opted in.

(Note that you can easily inspect a value’s binary representation by selecting the value in Regedit and choosing Edit | Modify Binary Data.)

I found that the opt-in stricter behavior is enabled if:

the EnableCertPaddingCheck registry value is present (any data type), and
the value’s data length is from 1 to 4 bytes, and
at least one of those bytes is a non-zero value.

Note that the registry value type does not matter, as long as the length and data requirements are met.

The opt-in stricter behavior is not applied if the EnableCertPaddingCheck value is not present, or if it is present and:

the EnableCertPaddingCheck registry value length is 0, or
the EnableCertPaddingCheck registry value length is greater than 4 bytes, or
the registry value length is from 1 to 4 bytes and all of the bytes are 0.

So, if EnableCertPaddingCheck is a REG_DWORD, which is always four bytes long, 0 opts out and any non-zero value opts in to the stricter validation behavior. In other words, Windows treats it the way it treats many similar “Enabled/Disabled” settings, which are usually implemented as DWORD values. Thus, it is intuitive and ideal to treat the value as a REG_DWORD, as the MS Security Guide administrative template does.

If the value type is REG_SZ, management of the setting is less intuitive, less manageable, and more mistake-prone. Note that string values are stored as a sequence of two-byte Unicode characters followed by a two-byte NUL terminator: 0x00 0x00. With EnableCertPaddingCheck as a REG_SZ:

The stricter behavior is enabled if the string value is one character that isn’t null bytes. For example, it’s enabled if you set it to the character “1” (0x31 0x00), the character “0” (0x30 0x00), or even the space character (0x20 00). With the two-byte NUL terminator automatically added, each of these examples would be four bytes long.
The stricter behavior is disabled if EnableCertPaddingCheck is an empty string: the value data is just the two-byte NUL terminator, 0x00 0x00. (Note that visually distinguishing an empty string from a single space character is a bit of a challenge.)
Also, counterintuitively, the stricter behavior is disabled if the string is more than one character long, because the data length is more than four bytes. For example, the stricter behavior would be disabled if the string value were “11”, or “1” with a leading or trailing space. (Again, noticing that extra space character would be a challenge.)

One would intuitively expect that setting it to the value “0” would disable the behavior, as it does when it’s a REG_DWORD, but that is not true when it’s a REG_SZ.

Microsoft’s documentation should have described EnableCertPaddingCheck as a REG_DWORD from the beginning, because Windows treats it like one. Given the long history of Microsoft’s describing it both as a REG_DWORD and a REG_SZ, compliance scanning tools should accommodate both.

Recommendations

Compliance validation tools should not fail the EnableCertPaddingCheck inspection for its value type. Ideally, it 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:

EnableCertPaddingCheck is a REG_DWORD, value exactly 1, or
EnableCertPaddingCheck is a REG_SZ, value exactly “1”.

Current references

WinVerifyTrust Signature Validation Vulnerability (CVE-2013–3900) (MSRC republished, 2022, updated in 2023 and 2024)
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900

ADV2915720 — Security Update Guide — Microsoft — Changes in Windows Authenticode Signature Verification
https://msrc.microsoft.com/update-guide/advisory/ADV2915720

Windows 11, version 23H2 security baseline
https://techcommunity.microsoft.com/t5/microsoft-security-baselines/windows-11-version-23h2-security-baseline/ba-p/3967618

Security Compliance Toolkit downloads (MS Security Guide administrative templates are included in the Windows security baseline downloads — get the latest one)
https://www.microsoft.com/en-us/download/details.aspx?id=55319

Archived articles

The following links are still visible online but are no longer being updated and should not be relied upon as references.

Microsoft Security Bulletin MS13–098 — Critical (published in 2013, updated in 2014)
https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2013/ms13-098

Microsoft Security Bulletin Summary for December 2013
https://learn.microsoft.com/en-us/security-updates/securitybulletinsummaries/2013/ms13-dec

Microsoft Security Advisory 2915720
https://learn.microsoft.com/en-us/security-updates/securityadvisories/2014/2915720