CVE-2013-3900 Mitigation: Compatibility Concerns with Legacy Applications

Enabling EnableCertPaddingCheck turns on the stricter Authenticode signature verification behavior introduced with MS13-098 and documented in Security Advisory 2915720. This behavior is opt-in, not enabled by default, and can be turned off again if needed.

Addressing the specific points:

• What is the recommended approach to identify impacted applications in advance?
  Advisory 2915720 explicitly recommends testing in the environment before fully implementing the change:

  “Microsoft recommends that customers test how this change to Authenticode signature verification behaves in their environment before fully implementing it.”
  Practical implications from the advisory:

  • The stricter behavior primarily affects portable executable (PE) binaries that are Authenticode-signed and verified via WinVerifyTrust.
  • Binaries most likely to be affected are PE installer files distributed via the Internet that are customized at time of download.
  • Impact is most visible when downloading and installing new applications whose signatures contain extraneous information in the WIN_CERTIFICATE structure.
  Recommended approach based on this:
  1. Enable EnableCertPaddingCheck first in a test or pilot group of representative servers/workloads.
  2. Exercise typical scenarios: software deployment, installer execution (.exe/.msi), updates, and any workflows that rely on signed binaries (including internal line-of-business apps).
  3. Pay particular attention to installers and update packages that are customized at download time or signed internally.
• Are there any tools or logs that can help detect failures related to this setting?
  The advisory does not define a special tool, but it describes the observable behavior:
  • When enabled, non-conforming binaries will appear unsigned and be rendered untrusted:

    “Non-conforming binaries will appear unsigned and, therefore, be rendered untrusted.”

  • Users may see warning messages when attempting to install new applications whose signatures fail the stricter validation:

    “…users may observe warning messages when attempting to install new applications with signatures that fail validation.”

  In practice, this means:
  • Look for installation failures or security prompts where previously the binary appeared signed/trusted but now appears unsigned.
  • For environments using AppLocker or Software Restriction Policies (SRP) based on publisher rules, watch for policy failures:
    • AppLocker:

      “Any AppLocker rule that depends on files being signed, or expects a specific publisher, may be impacted if the signature on a file does not meet the stricter Authenticode signature verification requirements.”

    • Software Restriction Policies:

      “Any Software Restriction Policy that depends on files being signed, or expects a specific publisher, may be impacted…”

  Monitoring for:
  • AppLocker/SRP event log entries where previously allowed binaries are now blocked.
  • Installer failures or security warnings during application deployment.
• Is there a supported way to whitelist or exclude specific applications, or is the only option to disable the setting if issues occur?
  The advisory describes only a global behavior switch via the registry; it does not document any per-application whitelist or exclusion mechanism. The documented options are:
  • Enable stricter verification by setting EnableCertPaddingCheck under:
    • 32-bit:
      HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config
"EnableCertPaddingCheck"="1"
    • 64-bit:
      HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config
"EnableCertPaddingCheck"="1"
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config
"EnableCertPaddingCheck"="1"
  • Disable the functionality by removing the registry value:
    • 32-bit:
      "EnableCertPaddingCheck"=- under ...\Wintrust\Config
    • 64-bit:
      "EnableCertPaddingCheck"=- under both ...\Wintrust\Config and ...\Wow6432Node\...\Wintrust\Config
  The advisory states:

  “Customers who are experiencing application compatibility problems with the new behavior… can disable the functionality by removing the EnableCertPaddingCheck registry key.”

  There is no documented per-binary or per-application whitelist; the supported control is on/off at the system level.
• What is Microsoft’s best practice for rolling this out in environments with legacy dependencies?
  From the advisory’s guidance and FAQ, the recommended best practices are:
  1. Treat the setting as optional and opt-in

     “The underlying functionality for stricter verification remains in place, however, and can be enabled at customer discretion.”
     “The stricter verification behavior… will reside on the system but will be dormant functionality until enabled.”

  2. Review and adjust signing processes before enabling

     “Microsoft recommends that customers ensure that their Authenticode signatures do not contain extraneous information in the WIN_CERTIFICATE structure.”
     “Executables authors [should] consider conforming their Authenticode-signed binaries to the new verification standard.”
     For internally signed executables and installers, ensure the signing pipeline produces strictly conforming Authenticode signatures.

  3. Pilot and test thoroughly
     • Enable EnableCertPaddingCheck in a limited, representative set of systems first.
     • Test:
       • Legacy applications and drivers that rely on Authenticode signatures.
       • Internal deployment/update mechanisms.
       • Any AppLocker/SRP rules that depend on publisher or signed-file conditions.
  4. Plan for remediation of non-compliant binaries
     If a binary is deemed non-compliant:

     “…that binary will need to be re-signed with strict adherence to the Windows Authenticode Signature format and specifically not include extraneous information in the WIN_CERTIFICATE structure.”

  5. Have a rollback path
     • If critical legacy software cannot be updated or re-signed, the documented mitigation is to remove the EnableCertPaddingCheck registry value and reboot, which restores the previous verification behavior.
  6. Understand policy impacts
     • For environments using AppLocker or Software Restriction Policies based on signatures, treat this as a policy change: rules may fail if signatures no longer validate under the stricter rules. Validate and adjust rules as needed during the pilot.

In summary, the supported model is a system-wide opt-in with thorough pre-deployment testing, remediation of non-compliant signed binaries (by re-signing), and the ability to fully disable the stricter behavior if compatibility issues with legacy applications or drivers cannot be resolved.

References:

• Microsoft Security Advisory 2915720