Exploited
7.6
CWE
20
Advisory Published
Updated

CVE-2013-3900: Microsoft WinVerifyTrust function Remote Code Execution

First published: Wed Dec 11 2013(Updated: )

<p><strong>Why is Microsoft republishing a CVE from 2013?</strong></p> <p>We are republishing CVE-2013-3900 in the Security Update Guide to update the <strong>Security Updates</strong> table and to inform customers that the EnableCertPaddingCheck is available in all currently supported versions of Windows 10 and Windows 11. While the format is different from the original CVE published in 2013, the information herein remains unchanged from the original text published on December 10, 2013.</p> <p>Microsoft does not plan to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows. This behavior remains available as an opt-in feature via reg key setting, and is available on supported editions of Windows released since December 10, 2013. This includes all currently supported versions of Windows 10 and Windows 11. The supporting code for this reg key was incorporated at the time of release for Windows 10 and Windows 11, so no security update is required; however, the reg key must be set. See the <strong>Security Updates</strong> table for the list of affected software.</p> <p><strong>Vulnerability Description</strong></p> <p>A remote code execution vulnerability exists in the way that the WinVerifyTrust function handles Windows Authenticode signature verification for portable executable (PE) files. An anonymous attacker could exploit the vulnerability by modifying an existing signed executable file to leverage unverified portions of the file in such a way as to add malicious code to the file without invalidating the signature. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.</p> <p>If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.</p> <p>Exploitation of this vulnerability requires that a user or application run or install a specially crafted, signed PE file. An attacker could modify an existing signed file to include malicious code without invalidating the signature. This code would execute in the context of the privilege in which the signed PE file was launched.</p> <p>In an email attack scenario, an attacker could exploit this vulnerability by sending a user an email message containing the specially crafted PE file and convincing the user to open the file.</p> <p>In a web-based attack scenario, an attacker would have to host a website that contains a specially crafted PE file. In addition, compromised websites and websites that accept or host user-provided content could contain specially crafted content that could be used to exploit this vulnerability. An attacker would have no way to force users to visit a website that is hosting the specially crafted PE file. Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that directs them to the attacker's website.</p> <p><strong>Update History</strong></p> <p>On December 10, 2013, Microsoft released an update for all supported releases of Microsoft Windows that changes how signatures are verified for binaries signed with the Windows Authenticode signature format. This change can be enabled on an opt-in basis. When enabled, the new behavior for Windows Authenticode signature verification will no longer allow extraneous information in the WIN_CERTIFICATE structure, and Windows will no longer recognize non-compliant binaries as signed. On July 29, 2014 Microsoft announced that it no longer plans to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows. To this date, it remains available as an opt-in feature in all currently supported releases of Microsoft Windows.</p> <p><strong>Recommendation</strong>. Microsoft recommends that executables authors consider conforming all signed binaries to the new verification standard by ensuring that they contain no extraneous information in the WIN_CERTIFICATE structure. Microsoft also recommends that customers appropriately test this change to evaluate how it will behave in their environments. Please see the <strong>Suggested Actions</strong> section for more information.</p>

Credit: secure@microsoft.com secure@microsoft.com

Affected SoftwareAffected VersionHow to fix
Microsoft Windows 10=20H2
Microsoft WinVerifyTrust function
Microsoft Windows 10
Microsoft Windows 10=20h2
Microsoft Windows 10=21h1
Microsoft Windows 10=21h2
Microsoft Windows 10=1607
Microsoft Windows 10=1809
Microsoft Windows 10=1909
Microsoft Windows 11
Microsoft Windows 11
Microsoft Windows 7=sp1
Microsoft Windows 8.1
Microsoft Windows RT 8.1
Microsoft Windows Server 2003=sp2
Microsoft Windows Server 2003=sp2
Microsoft Windows Server 2008=sp2
Microsoft Windows Server 2008=r2-sp1
Microsoft Windows Server 2012
Microsoft Windows Server 2012=r2
Microsoft Windows Server 2016
Microsoft Windows Server 2019
Microsoft Windows Server 2022
Microsoft Windows Vista=sp2
Microsoft Windows XP=sp2
Microsoft Windows XP=sp3
=1607
=1607
=21H2
=21H2
=21H2
=21H2
=21H2
=20H2
=21H1
=20H2
=21H1
=1909
=21H1
=1909
=1909
=1809
=1809
=1809

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2024 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203