msrc_cve-2013-3900
Vulnerability from csaf_microsoft
Published
2022-01-11 08:00
Modified
2024-12-23 08:00
Summary
WinVerifyTrust Signature Validation Vulnerability
Notes
Additional Resources
To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle
Disclaimer
The information provided in the Microsoft Knowledge Base is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
Customer Action
Required. The vulnerability documented by this CVE requires customer action to resolve.
{
"document": {
"aggregate_severity": {
"namespace": "https://www.microsoft.com/en-us/msrc/security-update-severity-rating-system",
"text": "Important"
},
"category": "csaf_security_advisory",
"csaf_version": "2.0",
"distribution": {
"text": "Public",
"tlp": {
"label": "WHITE",
"url": "https://www.first.org/tlp/"
}
},
"lang": "en-US",
"notes": [
{
"category": "general",
"text": "To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle",
"title": "Additional Resources"
},
{
"category": "legal_disclaimer",
"text": "The information provided in the Microsoft Knowledge Base is provided \\\"as is\\\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.",
"title": "Disclaimer"
},
{
"category": "general",
"text": "Required. The vulnerability documented by this CVE requires customer action to resolve.",
"title": "Customer Action"
}
],
"publisher": {
"category": "vendor",
"contact_details": "secure@microsoft.com",
"name": "Microsoft Security Response Center",
"namespace": "https://msrc.microsoft.com"
},
"references": [
{
"category": "self",
"summary": "CVE-2013-3900 WinVerifyTrust Signature Validation Vulnerability - HTML",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900"
},
{
"category": "self",
"summary": "CVE-2013-3900 WinVerifyTrust Signature Validation Vulnerability - CSAF",
"url": "https://msrc.microsoft.com/csaf/2022/msrc_cve-2013-3900.json"
},
{
"category": "external",
"summary": "Microsoft Exploitability Index",
"url": "https://www.microsoft.com/en-us/msrc/exploitability-index?rtc=1"
},
{
"category": "external",
"summary": "Microsoft Support Lifecycle",
"url": "https://support.microsoft.com/lifecycle"
},
{
"category": "external",
"summary": "Common Vulnerability Scoring System",
"url": "https://www.first.org/cvss"
}
],
"title": "WinVerifyTrust Signature Validation Vulnerability",
"tracking": {
"current_release_date": "2024-12-23T08:00:00.000Z",
"generator": {
"date": "2025-01-02T18:22:13.136Z",
"engine": {
"name": "MSRC Generator",
"version": "1.0"
}
},
"id": "msrc_CVE-2013-3900",
"initial_release_date": "2022-01-11T08:00:00.000Z",
"revision_history": [
{
"date": "2022-01-21T08:00:00.000Z",
"legacy_version": "1",
"number": "1",
"summary": "Information published in the Security Update Guide to update the Security Updates table and to inform customers that there are actions they need to take to protect their systems from this vulnerability. CVE-2013-3900 was originally published on December 10, 2013 on TechNet."
},
{
"date": "2023-04-11T07:00:00.000Z",
"legacy_version": "2",
"number": "2",
"summary": "In the Security Updates table, added the Server Core installation versions of the following versions of Windows as they are affected by the vulnerability: Windows Server 2008 for 32-bit Systems Service Pack 2, Windows Server 2008 for x64-based Systems Service Pack 2, Windows Server 2008 R2 for x64-based Systems Service 1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, and Windows Server 2022. Customers running these Server Core installations should review the FAQs and Suggested Actions section of this CVE and take action as necessary."
},
{
"date": "2023-05-09T07:00:00.000Z",
"legacy_version": "2.1",
"number": "3",
"summary": "In the Executive Summary, corrected information about Windows 10 and Windows 11 to state that 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. This is an informational change only."
},
{
"date": "2024-04-11T07:00:00.000Z",
"legacy_version": "2.2",
"number": "4",
"summary": "Updated FAQs to inform customers that EnableCertPaddingCheck is data type REG_SZ (a string value) and not data type dword. When you specify \u0027EnableCertPaddingCheck\" as in \"DataItemName1\"=\"DataType1:DataValue1\" do not include the date type value or colon. This is an informational change only."
},
{
"date": "2024-11-12T08:00:00.000Z",
"legacy_version": "2.3",
"number": "5",
"summary": "**Corrected** Correcting the published information from the previous revision. EnableCertPaddingCheck is data type REG_DWORD (an integer value) and not data type string: \"EnableCertPaddingCheck\"=dword:1. The FAQ section has been updated accordingly. This is an informational change only."
},
{
"date": "2024-12-23T08:00:00.000Z",
"legacy_version": "2.4",
"number": "6",
"summary": "Providing further clarification about how to configure the EnableCertPaddingCheck registry value to implement and revert the improvement to authenticode signature verification. Customers who had successfully followed previous 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. See the **Suggested Actions** section for more information."
}
],
"status": "final",
"version": "6"
}
},
"vulnerabilities": [
{
"cve": "CVE-2013-3900",
"cwe": {
"id": "CWE-347",
"name": "Improper Verification of Cryptographic Signature"
},
"notes": [
{
"category": "general",
"text": "Microsoft",
"title": "Assigning CNA"
},
{
"category": "faq",
"text": "Opting into the stricter verification behavior causes the WinVerifyTrust function to perform strict Windows Authenticode signature verification for PE files. After you opt in, PE files will be considered \u0026quot;unsigned\u0026quot; if Windows identifies content in them that does not conform to the Authenticode specification. This may impact some installers. If you are using an installer that is impacted, Microsoft recommends using an installer that only extracts content from validated portions of the signed file.\nCustomers who would like to enable the new Authenticode signature verification behavior can do so by setting a key in the system registry. When the key is set, Windows Authenticode signature verification will no longer recognize binaries with Authenticode signatures that contain extraneous information in the WIN_CERTIFICATE structure. Customers can choose to disable the functionality at any time by disabling this registry key. See Suggested Actions for instructions.\nCustomers who have already enabled the stricter verification behavior, and have not experienced problems, can choose to leave the verification behavior enabled. Customers who are experiencing application compatibility problems with the new behavior, or customers who simply want to disable the new behavior, can disable the functionality by removing the EnableCertPaddingCheck registry key or by setting it to REG_DWORD value 0. See Suggested Actions for instructions.\nNo. The stricter verification behavior resides on the system but will be dormant functionality until enabled.\nThe new stricter verification behavior, when enabled, applies primarily to portable executable (PE) binaries that are signed with the Windows Authenticode signature format. Binaries that are not signed with this format or that do not use WinVerifyTrust to verify signatures are not affected by the new behavior. Binaries most likely to be affected are PE installer files distributed via the Internet that are customized at time of download. The most common scenario in which users could perceive an impact is during the downloading and installation of new applications. This is the case only if customers have chosen to enable the stricter verification behavior, after which users may observe warning messages when attempting to install new applications with signatures that fail validation.\nFor customers who have chosen to enable the stricter verification behavior, 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.\nNo. The new verification behavior does not impact WDAC.\nFor customers who have chosen to enable the stricter verification behavior, any Software Restriction Policy 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.\nIf a binary is deemed non-compliant with the stricter Authenticode signature verification behavior, this will not be a problem on systems that have not had the new verification behavior enabled because Microsoft is not enforcing the stricter behavior by default. However, to correct problems with a binary failing validation on systems where the new verification behavior has been enabled, 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.\nYes. For customers opting to enable the stricter verification behavior, signing binaries with non-Microsoft-provided signing tools runs the risk of signatures being recognized as non-compliant with the stricter verification behavior. Using Microsoft products, or signature tools Microsoft provides, such as signtool.exe, helps to ensure that signatures are recognized as compliant.\nWindows Authenticode is a digital signature format that is used to determine the origin and integrity of software binaries. Authenticode uses Public-Key Cryptography Standards (PKCS) #7 signed data and X.509 certificates to bind an Authenticode-signed binary to the identity of a software publisher. The term \u0026quot;Authenticode signature\u0026quot; refers to a digital signature format that is generated and verified using the WinVerifyTrust function.\nWindows Authenticode signature verification consists of two primary activities: signature checking on specified objects and trust verification. These activities are carried out by the WinVerifyTrust function, which executes a signature check then passes the inquiry to a trust provider that supports the action identifier, if one exists. For more technical information regarding the WinVerifyTrust function, see WinVerifyTrust function. For an introduction to Authenticode, see Introduction to Code Signing.\nCustomers who are interested in learning more about the topic covered in this advisory should review Windows Root Certificate Program - Technical Requirements.\nAfter reviewing the technical details underlying the change in Authenticode signature verification behavior, Microsoft recommends that customers ensure that their Authenticode signatures do not contain extraneous information in the WIN_CERTIFICATE structure. Microsoft also recommends that executables authors consider conforming their Authenticode-signed binaries to the new verification standard. Authors who have modified their binary signing processes and would like to enable the new behavior may do so on an opt-in basis. Windows Root Certificate Program - Technical Requirements for guidance.\nTo enable the Authenticode signature verification improvements, configure the EnableCertPaddingCheck registry value to a non-zero value. Two ways that you can do this are through Group Policy, or with a .reg (\u201cRegistration Entries\u201d) file. Implementing the improvement through Group Policy is available via the \u201cMS Security Guide\u201d administrative template, downloadable with the most recent Windows security baseline in the Microsoft Security Compliance Toolkit. After the SecGuide.admx and SecGuide.adml files are copied into the administrative template store, enable the \u201cEnable Certificate Padding\u201d policy in Computer Configuration\\Administrative Templates\\MS Security Guide.\nTo implement the improvement with a .reg file, paste the following text into a text editor such as Notepad, save the file by using the .reg file name extension (for example, enableAuthenticodeVerification.reg). You can apply the .reg file to individual systems by double-clicking it. You can automate its application with the REG.EXE IMPORT command.\nFor 32-bit versions of Windows, use the following text:\nFor 64-bit versions of Windows, use this text:\nEarlier versions of CVE-2013-3900 had recommended configuring EnableCertPaddingCheck to string value \u201c1\u201d, 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:\nThe EnableCertPaddingCheck registry value is present (any data type), The value\u2019s data length is from 1 to 4 bytes, At least one of those bytes is a non-zero value\nCompliance 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:\nEnableCertPaddingCheck is a REG_DWORD, value exactly \u0026quot;1\u0026quot;, EnableCertPaddingCheck is a REG_SZ, value exactly \u0026quot;1\u0026quot;\nTo revert to Windows default behavior and disable the Authenticode signature verification improvements, delete the EnableCertPaddingCheck registry value or set it to a DWORD value 0. Two ways that you can do this are through Group Policy, or with a .reg (\u201cRegistration Entries\u201d) file.\nTo revert the improvement through Group Policy, configure the \u201cMS Security Guide\u201d policy described in Implement the Improvement to Authenticode Signature Verification to \u0026quot;Disabled\u0026quot;.\nTo revert the improvement with a .reg file, paste the following text into a text editor such as Notepad, save the file by using the .reg file name extension (for example, disableAuthenticodeVerification.reg). You can apply the .reg file to individual systems by double-clicking it. You can automate its application with the REG.EXE IMPORT command.\nFor 32-bit versions of Windows, use the following text:\nFor 64-bit versions of Windows, use the following text:",
"title": "What is the result of opting into the stricter verification behavior?"
}
],
"product_status": {
"fixed": [
"9312",
"9318",
"9344",
"10049",
"10051",
"10287",
"10378",
"10379",
"10483",
"10543",
"10729",
"10735",
"10816",
"10852",
"10853",
"10855",
"11568",
"11569",
"11570",
"11571",
"11572",
"11923",
"11924",
"11926",
"11927",
"11929",
"11930",
"11931",
"12085",
"12086",
"12097",
"12098",
"12099",
"12242",
"12243",
"12244",
"12389",
"12390",
"12436",
"12437"
],
"known_affected": [
"1",
"2",
"3",
"4",
"5",
"6",
"7",
"8",
"9",
"10",
"11",
"12",
"13",
"14",
"15",
"16",
"17",
"18",
"19",
"20",
"21",
"22",
"23",
"24",
"25",
"26",
"27",
"28",
"29",
"30",
"31",
"32",
"33",
"34",
"35",
"36",
"37",
"38",
"39",
"40"
]
},
"references": [
{
"category": "self",
"summary": "CVE-2013-3900 WinVerifyTrust Signature Validation Vulnerability - HTML",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900"
},
{
"category": "self",
"summary": "CVE-2013-3900 WinVerifyTrust Signature Validation Vulnerability - CSAF",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900"
}
],
"scores": [
{
"cvss_v3": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"environmentalsScore": 0.0,
"exploitCodeMaturity": "UNPROVEN",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"remediationLevel": "OFFICIAL_FIX",
"reportConfidence": "CONFIRMED",
"scope": "UNCHANGED",
"temporalScore": 4.8,
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N/E:U/RL:O/RC:C",
"version": "3.1"
},
"products": [
"1",
"2",
"3",
"4",
"5",
"6",
"7",
"8",
"9",
"10",
"11",
"12",
"13",
"14",
"15",
"16",
"17",
"18",
"19",
"20",
"21",
"22",
"23",
"24",
"25",
"26",
"27",
"28",
"29",
"30",
"31",
"32",
"33",
"34",
"35",
"36",
"37",
"38",
"39",
"40"
]
}
],
"threats": [
{
"category": "impact",
"details": "Security Feature Bypass"
},
{
"category": "exploit_status",
"details": "Exploited:Yes;Latest Software Release:Exploitation Detected;Older Software Release:Exploitation Detected"
}
],
"title": "WinVerifyTrust Signature Validation Vulnerability"
}
]
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.